HP should save the enterprise from Windows 8

With Microsoft bringing their own branded tablets to market, what is left for major OEMs like Hewlett Packard? One's first reaction may be to consider trying to do one better with the hardware. While this is still possible, maybe HP should consider getting back into the software business.

HP is making a good decision by concentrating on the x86 platform, rather than ARM in future tablets. Windows RT is untested at this point. Also Windows RT will not run the huge existing x86 based Windows software base that dwarfs any current app store in quantity and quality. There can be many advantages to HP's current decision.

Microsoft has made some choices in the past decade that demonstrate they have lost appreciation for the value of backward compatibility. This was once Windows biggest strength, but it is now changing. Dropping classic Visual Basic for VB.NET was the first step. Pushing managed programming languages (aka. .NET) and the .NET frameworks was the next step. Windows 8 and its new Metro interface has been the pinnacle of this mindset. While consumers may flock to Metro and the App Store model, power users and especially business users will be more concerned with a more practical approach of backward compatibility. To appreciate the significance of backward compatibility and how it made Windows what it is today read Joel Spolsky's discussion about this.


HP has an opportunity to build its own unique software, to go with its hardware, which can give it an edge over Microsoft. How? Microsoft sadly has lost appreciation of how important backward compatibility is, but HP can use this to their advantage. How?

While Microsoft in their own software development has to a degree abandoned backward compatiblity, the operating system hasn't totally lost this. Windows 8, aside from Metro, still supports the Desktop. The interesting thing about the Windows 8 desktop is that it does an amazing job of running older software and the WIN32 APIs are still quite intact. I have done extensive testing of this and I have found that one can easily write complex software that can run on a wide-range of Windows platforms from Windows 95 to Windows 8. Now HP really only needs to concentrate on Windows XP to Windows 8, which is actually not that difficult. Business users will appreciate modern software that will run just as well on their Windows XP machines as it does in Windows 8. Software can also be designed to poll the operating system and then dynamically impliment features based on which ever version of Windows it is being run on.

Build Better Software

Can an OEM like HP build better software than Microsoft ? If they want to, absolutely! Watch Herb Sutters (Microsoft C++ expert) talk "Why C++?" and see how he describes the industry's failure to develop software with performance in mind. Now as a long-time Windows API developer myself, I will go one step further than Sutter. I lay the blame on managed programming languages and the industry's obsession with Object Oriented Programming. The majority of programmers will likely not agree with this observation, but I strongly feel that we have lost sight of how to build software with a small footprint and excellent performance.

I am not alone in this viewpoint either. How software is designed can determine whether it is efficient or not. Also targeting hardware directly using programming languages that can leverage the power of CPU as well as the operating system provides manufacturers the ability to build software with a small footprint and high performance that can significantly improve the user experience on tablet computers. There are those experienced in software development who recognize that current development methods, particularly object oriented programming, don't always produce the high performance software end users desire.

What Others are Saying

Alexander Stepanov:

Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper's Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele).

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting -- saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

Also found at:


A more balanced understanding of his views of OOP can be found in this paper of his: http://www2.research.att.com/~bs/oopsla.pdf

Richard Mansfield:

His white paper entitled "Has OOP failed ?" broaches this subject. Richard Mansfield has a very long history in technology. He was the editor of Compute magazine for about 7 years and has written dozens of computer / programming books which in total have sold about 500,000 copies. A number of his books were on Visual Basic .NET so he obviously had plenty of experience using OOP based languages.

To quote Mansfield: "There's no evidence that the OOP approach is efficient for most programming jobs. Indeed I know of no serious study comparing traditional, procedure-oriented programming with OOP. But there's plenty of anecdotal evidence that OOP retards programming efforts. Guarantee confidentiality and programmers will usually tell you that OOP often just makes their job harder",

Asaf Shelly:

I found this interesting blog on the Intel web site with an article entitled "Flaws of Object Oriented Modeling" .

The author makes this comment about OOP: "Now it is almost impossible to follow the execution flow. When you want to know what happened in your application when the error message popped up you have to go over all the objects and all the classes that the execution flow went through and many times execution flow travels between several member functions before leaving to another object. Following the execution flow today is almost impossible".

Stephen C. Johnson (Melismatic Software):

"Object-oriented programming (OOP) is an ancient (25-year-old) technology, now being pushed as the answer to all the world's programming ills. While not denying that there are advantages to OOP, I argue that it is being oversold." and also "Object-oriented languages tend to burn CPU cycles, both at compile and execution time, out of proportion to the benefits they provide".

Bjarne Stroustrup:

Said to be the designer and original implementor of C++ makes some interesting comments in an interview: "Well. It was obvious to me 20-some years ago that OOP wasn't a panacea. That's the reason C++ supports several design and programming styles" and "In the first edition of "The C++ Programming Language," I didn't use the phrase "object-oriented programming" because I didn't want to feed the hype. One of the problems with OOP is exactly that unscrupulous people have hyped it as a panacea. Overselling something inevitably leads to disappointments".

"That said, OOD/OOP is my favorite way of approaching design and programming. It just isn't the right style for every program and for every detail of a program. Some good abstractions are best represented outside class hierarchies. Trying to force everything into a hierarchy -- especially into a single-rooted hierarchy - can give truly contorted programs".

Chris Turner:

He describes himself as "an agile architect and developer specialising in building large, scalable enterprise and Internet solutions". In his blog he makes some interesting comments such as "I have therefore been moving away from the object-oriented development principles that have made up the bulk of my 17 year career to date. More and more I am beginning to feel that objects have been a diversion away from building concise, well structured and reusable software." and concludes by saying "I'm certainly building smaller, cleaner and better structured software than I ever was before".

Dermot Hogan (Bitwise magazine technical editor):

He says "in the twenty or so years since object-oriented programming emerged from the universities, there is not one single documented, cast-iron, nailed-to-the-ground, proven case study that OOP works." and also "On the contrary, there is solid evidence that OOP doesn't work. Just look around you at the numerous failed, over budget disasters in the IT industry".

Department of Computer. Science and IT, University of Jammu:

"The use of object-oriented technology (OOT) has been shown to be of great value in many market sectors, but to the use of such technology within embedded systems remain a challenge. Such systems require high execution speed and have high memory constraints" and " The object-oriented approach is known to introduce a significant performance penalty in terms of memory and time compared to classical procedural programming. In this paper, we have analyzed the execution speed of the different programs generated by the compilers of C and Java. The investigation shows that the speed of execution shows considerable difference between the Object Oriented and procedural programming languages"; and they come to an interesting conclusion when they say "It is concluded that the Object Oriented Programming languages proves to be slower than the procedural programming languages in terms of execution speed than there counterpart".

Multicore CPU's Only mask the Real Problems

Many of my peers will likely suggest that multicore CPU's solve the problems with performance. True, developing software that leverages multicore CPU's will make a big difference but I feel compelled to add that multicore CPU's only mask the problem, rather the solve the problem. Why?

As a simple example, while I am writing this article on my Windows XP (SP3) computer, I have one instance of Windows Explorer 8.0 running, displaying the current BetaNews web page. When I run task manager IE actually runs two different instances (processes) of itself , one using about 16MB RAM, 7MB virtual memory, 14 threads and the other using about 134MB RAM, 125MB virtual memory, 24 threads. Just displaying one web page is costing me 150MB RAM, 132MB virtual memory and 38 threads. Rather than be an improvement, software for Windows 7 and Windows 8 will likely have similiar problems.

Now add to this all the background processes running on any typical Windows computer and you may have dozens of threads running using a significant amount of memory. While Windows 8 may have been improved overall, once you start running a few apps forget about performance and multicore CPU's, while an improvement, don't solve the core problem which is poorly designed software which over uses hardware resources.

What this means for Hewlett Packard is that the hardware specs alone won't make the difference. If they want to build better tablets than Microsoft, the software experience also has to improve. Now does anyone really expect the Windows 8 Pro Surface tablet to cost much less than a $1,00 ? Not likely. Why? Because to provide the proper-end user experience, heavy-duty hardware is required. Have you ever wondered why at the BUILD conference the tablet provided to developers had a heavy duty multicore CPU in it? Because you need a powerhouse CPU to compensate for the performance lacking Visual Studio.

I downloaded a recent Visual Studio beta and installed it on a system with a Pentium D 3.2GHz dual-core CPU (2MB RAM), on which I had installed Windows 8. While Windows 8 runs very well on this computer, Visual Studio is so slow it amazes me. When the development tools programmers use today are so bloated that they require heavy-duty multicore CPUs just to run acceptably and they use as much disk space as some operating systems, then something is wrong.

End users often make comparisons between computing devices, such as tablets, by their hardware specifications. When you see a device with a quad-core CPU instead of a dual-core, one is quick to assume that you will get a significantly better experience. Sadly, some of the experience will be lost to software bloat. Yes, that better CPU means a faster computer, but will a percentage of that experience be lost to increasing software bloat?

To take a quote from Wikipedia:

"Niklaus Wirth has summed up the situation in Wirth's Law, which states that software speed is decreasing more quickly than hardware speed is increasing".

To take some quotes from IBM's web site:

"Based on our 8 years of experience solving performance problems, we have found that runtime bloat in real Java applications is pervasive".

"Bloat is a systemic problem, resulting from a software engineering culture encourages abstraction and layering, with a goal of rapid application development".

HP, Go Back to the Basics

Since the days of the early computers, something was lost along the way.

To quote the wikipedia article again:

"Software developers involved in the industry during the 1970s had severe limitations on disk space and memory. Every byte and clock cycle counted, and much work went into fitting the programs into available resources. Achieving this efficiency was one of the highest values of computer programmers, and the best programs were often called "elegant"--seen as a form of high art...

"This situation has now reversed. Resources are perceived as cheap, and rapidity of coding and headline features for marketing are seen as priorities...

"Niklaus Wirth has summed up the situation in Wirth's Law, which states that software speed is decreasing more quickly than hardware speed is increasing".

While HP likely can produce a simliar quality Windows tablet compared to Microsofts Surface, maybe what they really need to do is concentrate on the entire end-user experience. By building better software with a small footprint and significant performance, HP could even offer lower-cost tablets that would better appeal to businesses and consumers alike. Editor: Didn't HP already try this, and give up, with TouchPad and webOS?

Netbooks became popular, not just because of their small form factor, but also because of their extremely low price. Could HP be the first to build a $200 Windows 8 (x86) tablet? It may be possible. Intel's StudyBook tablet concept is a great idea, but the cost is too high. A 7-inch Windows 8 (x86) tablet in the $200 range is definitely possible, but it would require the software to match. Even Microsoft's Windows RT Surface tablet is likely going to be in the $500 range from what I gather so far, which is not that impressive to me.

If Microsoft can get into the hardware business, maybe HP needs to get into the software business. There are advantages of building the software to match the hardware. While Microsoft is likely building the hardware to match their software, HP could do the reverse and start building the software to match their hardware, but just doing it one better and opting for a small footprint and performance.

Build a Bridge Between the Desktop and Metro

Metro will be a big change for many people, while the desktop, refered to as legacy, is not dead yet and may have a much longer life span than even Microsoft may think. What is needed is a better bridge between the two. HP could provide this with well-designed software that better bridges the two. Businesses shouldn't have to replace all their computers with Windows 8 PCs (or upgrade them all), but they should be able to easily integrate a few new Windows 8 computers (and the software) with their existing computer base. Obviously some software must be designed for Metro, but the desktop is not dead yet and that needs to be concentrated on.

While Metro apps will only run on Windows 8, desktop apps can run on many current versions of Windows, too. Why would a business want an application that can only run on Windows 8? Now if HP could design software that could span all the different versions of Windows, including Metro, to provide a better overall experience, this could provide them with an advantage. HP can build for the desktop first, while building secondary apps (with similiar functionality) which support Metro as well. The enterprise would definitelly appreciate this and HP could offset low-profit margins of the hardware by selling more software.

For example, imagine buying an HP Windows 8 tablet that comes with a DVD with a suite of tools which not only runs on Metro (Metro versions), but also can run on Windows XP, Vista and 7 machines (desktop versions). If you buy their tablet, they could offer a special OEM price for buying extra DVDs of the same software suite to run on your Windows XP or 7 desktops. In the end, software is what makes the difference!

If HP wants to move into the twenty-first century, then maybe they, too, should become a hardware and software business -- the latter, again. Apple does it. Google is now doing it and so is Microsoft.

Photo Credit:  drserg/Shutterstock

Chris Boss is an advanced Windows API programmer and developer of 10 year-old EZGUI, which is now version 5. He owns The Computer Workshop, which opened for businesses in the late 1980s. He originally developed custom software for local businesses. Now he develops programming tools for use with the PowerBasic compiler.

16 Responses to HP should save the enterprise from Windows 8

  1. conan007 says:

    "HP is making a good decision by concentrating on the x86 platform, rather than ARM in future tablets." Please, where did you read this? HP just said it will do x86 for now; it did not say it would definitely not do ARM "in the future".

    • ilev says:

      No OEM will do, in the present or future, ARM tablets, after Microsoft extorting $85-95 for Windows RT license.

      Regarding HP and Enterprise. It is realy simple. HP should sell Windows 8 Pcs (desktops, laptops...) with clean Windows 8 desktop only, ditching Metro alltogheter.

      • And you think that HPs OEM license would allow them to modify Windows 8 to the extent that it does not include Metro?

      • worleyeoe says:

        Dude, you are smoking some serious crack if you think MS is going to get anything close to $85-95 for WinRT. Go do some Windows OEM licensingi research. With the pricing pressure MS is under, it's unlikely that WinRT will be more than $45-50 at most. There's no way. Good gawd, man, Amazon and Google are going to be eating Apple's and MS' lunches if their products aren't competitively priced. And MS knows this more than Apple. FYI, XP was licensed for $25, so $25 for WinRT and $25 for Office is all they'll realistically be able to get. W8 Pro licensing will be about $60-70 for the big boys like HP, Dell and Lenovo. And MS could easily give discounts for increased quality and tablets that don't come loaded with extra bloatware.

  2. seste beste says:

    @conan007: i´ve read it here - never say never, but for now it seems like that.

  3. Dwedit says:

    "Object oriented programming" literally means code where the first parameter of a function is a "This" pointer.  The "this" pointer points to a struct containing all the variables of the object.  That's all it is.  You can make object-oriented code even in languages that don't directly support it, like C or even Assembly, just by writing and calling functions where the first parameter is the "this" pointer.  Blaming "Object Oriented programming" for bad performance is missing the mark.  Mountains of bad code that hide underneath friendly-looking objects is still bad code no matter which programming paradigm produced them.

    One of the few ways that object-oriented programming can cause
    performance loss is virtual methods.  Since they get called via a
    virtual function table instead of a funciton call, the code can no
    longer be inlined.  Inlining is generally a good thing because it
    reduces stack use and other function call overhead.
    The other way object-oriented programming can produce bad code is excessive copying, and that's a problem from misusing the language.  Passing large objects by value is bad, but easy to do inadvertently.  Or sometimes you need your arguments to be modifiable, so they get copied.  One shortcoming of C++ itself is that there is no good way to return a large object form a function.  Even if it's going into a variable, it gets copied several times along the way.  C++11 tried to fix some of the copying problems with rvalue references, but this hasn't caught on yet.  Other programming languages (like C#, lua, javascript, etc) simply made everything into a reference, so there would be no more copying.

    The key to performance is to reduce memory use, and make sure the code that gets run a lot is well-optimized "fast code".  Infrequently executed code can be as slow as it needs to be.  The "slow code" could even be run in an interpreter.  Performance can be good enough as long as the interpreter itself isn't a memory hog, and the overhead to call the fast code remains low.
    The other way to improve performance is to make code get run less often.  Sometimes using the correct algorithm (hash tables vs linear search) can make a difference.  Even a simple "dirty flag" can improve things dramatically, so that code knows that it doesn't need to re-do a task.

  4. Supetra Rahadiyono says:


  5. cool_guy says:

    Since we are talking about HP and software.....The webOS portal remains open. HP can go through it any time they want. They could have taken Microsoft head on....Just imagine. At least people "like" webOS....The failure of webOS is no one's fault but HP themselves. It is their own fault they shipped under powered laggy devices so they got bad reviews. What did they think? Spend little, gain big? No....

    HP's biggest mistake:

    Discontinuing the TouchPads - (because people actually liked webOS. You don't take away product like that. If you realize where you went wrong the first time, you have another go and make it better the second time...oh and You do NOT just quit)

  6. sharpdesigner says:

    With Microsoft bringing their own branded tablets to market, what is left for major OEMs like Hewlett Packard?
    Can I ask "With Google bringing its own brander tablet(s) and phone(s), what is left for major OEMs like Samsung, HTC?"
    I didn'tsee people barking about this question. But, whatever comes from Microsoft, people will always manage to extract the -ve aspects. First, the very people bark about not having "cool" windows machines. Now, Microsoft shows how a non-ipad looking tablet can be made and it can still be attractive, all of a sudden everyone is crying foul about the deaths of OEMs. Why??? What's the agenda behind all these -ve Microsoft articles @ BN? Who is paying you guys???

  7. I think the title should be changed a bit to reflect what the author is actually trying to say...I was ready for a fight, no longer. Though it really concerns me that the gentleman is still using an XP3 PC, I started a job somewhere having to use one and was ready to wreak havoc before finally getting my 7 tower. I can understand to a degree a person's affinity for nostalgia and the way things used to be, but seriously move on. It's only good to have reminders but not be dependant on them.

  8. Brad Buhrkuhl says:

     I am writing this article on my Windows XP (SP3) computer"
    How can you possible take a tech writer that is so far behind the curve seriously.  Articles like this make me want to ditch BetaNews completely.  (Do they have filtered RSS feeds to remove certain authors?)

  9. Flydog57 says:

    I disagree.  I've been in this business since the Xerox PARC folks filled an issue of Byte magazine with articles about Smalltalk (that issue was released about 3 weeks after I started my first job).  I wouldn't go back to the toolset I used in the early 80s if you were to double my salary.
    Worrying about CPU cycles can be important, but it often isn't.  Moore's Law has increased the number of CPU cycles available to programmers by many orders of magnitude in the past several decades.  During that time, my typing skills may have gotten slightly better, and I haven't noticed any great increases in the skills of my peers.
    But, I have seen many noticeable increases in programmer productivity.  None of those are based on the advances that C++ has made (though RValue references do help - not that many C++ programmers understand them).
    The rocket-science C++ programmers may be capable of hand-coding non-object-oriented C++ that runs faster than a comparable C# programmer can, but the differences will be measured in percentages.  However, a journeyman C++ programmer can write code that is more than an order of magnitude slower than code that Herb Sutter or Alexander Stepanov might write.  In fact, in the late nineties I worked for a company and the first thing I did there was reduce the start-up time for a UI from slighly over 2 minutes to 15 seconds (for the first time it ran, it was only 5 seconds for subsequent runs).  You don't have to be a bad programmer to write bad C++ code - many average programmers are very capable of doing that without thinking too hard.
    It's a lot harder to write bad C# (or modern VB, or Java, or...) than it is to write bad C++.

    Here's an anecdote.  I had a customer at a financial institution.  He had written a Monte-Carlo simulation that he used to evaluate packages of securities (over time).  It was written in VB6 and it was slow.  He went to a conference and people said "oh, you need to write that in C++ to get any performance".  That's when I got involved.  It was a simple, CPU-bound calculation (no UI, no significant library/framework dependencies) that was easy to convert from VB6 to VB.NET.  That change sped it up by about a factor of 2.5 to 3.  Then I realized that he was using a Decimal (fixed point) type but, because of the library calls he was using, he was only getting Double (floating point) accuracy.  Moving from Decimal to Double increased performance by nearly another 50%.  Then I used Reflector and converted it to C# (it ran at the same speed - no suprise there).  That was the first day.  The next day, I converted it to C++ using the obvious libraries.  That first try ran at less than 1/2 the speed of the C# code.  A bit of profiling, and it was obvious that the date calculations were the culprit (every call tried to figure out daylight savings time).  I switched to a different date/time library and I got it to within 20% of the C#, but still slower.  I eventually went to the NT "FileTime" libraries and the code ran at about the same speed as the C# (perhaps slightly slower, definitely not faster).  Finally, I wrote my own date calculation code (as a class, not as a non-object-oriented library) and I was able to get the C++ to about 5 or 10% faster than the C#.  However, those 3 pages of code took me more than a week to hand-optimize.  The .NET code was definitely good enough (in fact, the customer ended up using the VB.NET version - he had experience in the language).
    Yes, object-oriented calls require an extra level of indirection, and, in addition to the CPU cycles that might cost you an extra page fault the first time you make the call.  JIT compiled languages (like the .NET lanaguages and modern Java) do have a start-up cost.  However, the two most expensive things in programming these days are programmer skill-sets (rocket-science level coders are hard to find) and page-faults.  CPU cycles and (to some extent) memory are not were the cost lies.  A JIT compiled language usually does have a good optimizer (not necessarily as good as a C++ optimizer, but...) but it can also do a better job of laying out code to minimize page faults.  Modern languages, libraries and frameworks are much more approachable than C++ and it's easier to write code that isn't bad.  Yes, C++ and the STL are amazing, but a read through Meyers' "Effective STL" should convince you that you need to think very hard to write great code using that combination.
    I read Spolkey's post way back when it came out.  What he didn't point out was that programming was going to move away from Win32 whether Microsoft released the .NET Framework or not - programming was moving away from the desktop to the server (and it has since moved to a combination of servers and mobile devices).  And, for what it's worth, apps that are based on massively multi-threaded server code (like say web apps) generally run faster when they use a pin-and-sweep garbage collector (like that used by .NET and Java) than they do in a deterministic finalization language like C++.
    Finally, some of your statements are, uh, "interesting".  For example: "I downloaded a recent Visual Studio beta and installed it on a system with a Pentium D 3.2GHz dual-core CPU (2MB RAM), on which I had installed Windows 8. While Windows 8 runs very well on this computer, Visual Studio is so slow it amazes me."  Geez, beta code runs slow; are you surprised.  Similarly, "When I run task manager IE actually runs two different instances (processes) of itself , one using about 16MB RAM, 7MB virtual memory, 14 threads and the other using about 134MB RAM, 125MB virtual memory, 24 threads. Just displaying one web page is costing me 150MB RAM, 132MB virtual memory and 38 threads."  Try writing a web browser where you value the number of threads and the amount of memory used higher than performance and see whether it catches on.  Yes, modern web browsers are resource intensive, but they are also *way* more performant than they were a decade ago.
    Anyways, it's Friday, I've ranted enough.

  10. chrisboss says:

    When I mention that I still use Windows XP, please don't conclude that I don't use a more current OS at all. I have a Vista PC (which currently is doubling to run Windows 8), a WIndows 7 desktop, Windows 7 laptop, Windows 7 tablet also dual booting Windows 8.

    I just like to develop on XP so I can optimize software for older PC's and then test on Windows 7 (and 8).

    Also to quote Herb Sutter in his talk "Why C++?" he basically says the industry has been "pathetic" when it comes to performance for the last 10 or so years. Programmers may feel they are more productive with todays tools, but one word describes much of the software created today which is "bloated". This shows up especially on Windows tablets running Atom CPU's. Lastly, most developers develop on leading edge PC's while many end users are using low end (to mid level) PC's. End users are more likely not to experience "fast and fluid" software, despite developers thinking their software is plenty fast enough. Also tablets come with small SSD's rather than large harddrives, so disk space once again is at premium. This means the size of an application is important again.

  11. ilev says:

    $85-95 is the number stated by OEMs last month for Windows RT license price.
    This will stick and Windows RT surface price will be ~$500.
    Jeremy Blosser
    HP will be able to tweak Windows 8 whatever way they want and Microsoft will kneel, otherwise Microsoft may lose the no.1 PC seller.

  12. ajcVeteran says:

    First off, when I tested Windows 8 beta on a desktop PC, it only took me minutes to realize it is made for a touch screen tablet, not a normal PC. I uninstalled it it a day later. Second, for both marketing and practical reasons, Microsoft's new tablet with its fold out keyboard should be an 8" item minus the attached keyboard to go with its or Apple, Google and Samsung's small tablet's [Apple will release one smaller than its popular  but expensive iPADs no doubt] will crush a for decades virus prone [unacceptable that this still is true considering just how long Windows corp and its Windows OS has been around...] Windows. I just don't see even 200,000 people buying this thing from Microsoft in its present form. They should fire the person that rolled it out and get someone more current market savvy.

© 1998-2020 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.