Windows 8: More early clues start to emerge

Windows 8: More early clues start to emerge

Summary: As soon as Microsoft releases the final bits of a new Windows release to manufacturing -- and often before -- many users' thoughts turn to what's next. Windows 7 was released to manufacturing in late July. By late August, Microsoft's Windows client unit already was turning the crank on Windows 8 client and server.

SHARE:

As soon as Microsoft releases the final bits of a new Windows release to manufacturing -- and often before -- many users' thoughts turn to what's next.

Windows 7 and its server complement, Windows Server 2008 R2, were released to manufacturing in late July. By late August, Microsoft's Windows client unit already was turning the crank on Windows 8 client and server.

Anders Vindberg, a Microsoft Technical Fellow in Microsoft's Management and Services division -- a "Big Brains" interview with whom I'll be posting soon -- acknowledged that planning sessions were well underway for Windows 8. And of the 12 working groups created, "eight or nine revolve around management." (Back in April of this year, Microsoft was seeking developers interested in working on some of these management features and enhancements to Distributed File System Replication for Windows 8.)

Stephen Chapman, a tech enthusiast who runs the UX Evangelist site, has been beating the bushes for a few months now for Windows 8 information. He recently unearthed a number of job profiles of folks who have worked on and are working on various elements which may or may not make it into the final Windows 8 release.

Chapman found listings regarding tweaks being made to the Hibernate/Resume/Integration programming interface "that can integrate and utilize the new TLZ file compression engine." (I'm not really sure what TLZ means here. I found a reference to TLZ as a file extension for Tar (.TAR) file compressed with LZMA (.LZMA) file compression "most commonly used on Unix systems.")

He also found a reference to more tweaks that Microsoft is making around kernel patch protection, via PatchGuard. Chapman blogged that, based on what he unearthed, "PatchGuard is apparently going to make life even a little more difficult for hackers (and anti-virus companies as well, perhaps)."

Things are happening on the Windows 8 Server front, too. It seems that the Dublin application server that Microsoft has been readying might find its way into Windows 8 Server, based on another online resume Chapman found. (Microsoft officials said last year that the grand plan for Dublin was to integrate it into Windows Server, but never said when.)

I've seen a few Windows 8 references out there focused around the server version that mention new functionality Microsoft is working on to make Windows 8 Server an even stronger datacenter operating system. That dovetails with Microsoft's slow but steady push toward offering customers not just a public-cloud hosting capability, but also a private one. For Microsoft, a private cloud will revolve around Windows Server. Some of the features/functionality developed by the Windows Azure operating system (Red Dog) team will undoubtedly find their way back into future iterations of Windows Server.

It's still early. Windows 8 is unlikely to debut until 2011, at the earliest, given the way Microsoft is delivering Windows releases these days. I'll be interested as to how Microsoft execs characterize Windows 8, given they decided to deem Windows 7 a "major" release and Windows Server 2008 R2 a "minor" one.

Anyone else hearing any scuttlebutt yet on Windows 8? What are you hoping gets included in the next Windows client and server releases?

Topics: Operating Systems, Hardware, Microsoft, Servers, Software, Windows

About

Mary Jo has covered the tech industry for 30 years for a variety of publications and Web sites, and is a frequent guest on radio, TV and podcasts, speaking about all things Microsoft-related. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008).

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

274 comments
Log in or register to join the discussion
  • Here's something for the developers to do:

    Spend 100% of their time on the current windows, until it is bug-free, secure, and stable.

    Also for the next Win, don't change the UI again. Please.
    gtvr
    • pray do tell

      which OS is 100% bug free OS and has some form of functionality to it. That would save us all the trouble of wondering which that could be.
      Snarfiorix
      • Interesting...

        ...so if there's currently no bug free and functional OS then MS should not strive to attain that goal...
        storm14k
        • False Choice Fallacy...

          Ever stop to think that maybe after something like 50 years that operating systems have been around that nobody has yet to create a bug free one yet?

          Do you develop software? If so then you are familiar with the process of triaging bugs, weighing their severity against the cost to fix.

          A threashold must be set because if it was at 100% as you suggest the software would NEVER SHIP.
          BFD
          • However...

            A fatalistic acceptance that software has bugs and lots of them isn't exactly helping convince coders that one of their aims is being bug free.

            There are plenty of mind numbingly complex things that people build out there that aren't software that give far less problems and work for far longer, so software people should really step up rather than pushing the "So what? All software has issues" barrow as is the (modern) tendency.
            zkiwi
          • It's not fatalistic...

            It's actually quite the opposite. People realize that most bugs are either not serious and/or have easy workarounds. There aren't real analogs outside of software, because there is frankly nothing nearly as complex. Microprocessor design is far less complex, architecture and structural engineering doesn't have the complexity, medicine doesn't have the complexity.

            If you want software to be more stable you should make that your top requirement. Say, "I don't want a GUI. That abstraction itself is rather complex. Pure command line. Lets get rid of memory management. For storage, I'll read the sectors off the disk myself... I don't need a complex file system." You can have a great circa 1960 system with basic wordprocessing (no spell checking and word wrap, but you can type and delete) and a solid calculator.

            But I think most people would prefer Halo 3 or HalfLife 2, or Firefox, or Visual Studio... bugs and all.
            DevStar
          • Nice try...

            But software is not the most complex thing out there. Software is not a "special case" where normal design and complexity rules do not apply.
            zkiwi
          • @zkiwi...

            ...you've obviously NEVER worked on an operating system or anything more complex than "Hello world!".

            If you think that it's simple to write an operating system, I invite you to apply for a job at Microsoft and show them how to do it because I'm quite that you'll be able to show them just how easy it is and that the thousands of engineers they've employed over the years were nothing more than hacks.

            Yeah, try telling Raymond Chen or Larry Osterman that they're hacks. Go ahead, prove them wrong, make it as simple as, oh, breathing.
            PollyProteus
          • re "it's not fantastic"

            "But I think most people would prefer Halo 3 or HalfLife 2, or Firefox, or Visual Studio... bugs and all. "

            its "developer" arrogance like this, that has given us this problem.

            "you'll get what you are given, even if it does not work, because , WE, know that's what you want!

            I would agree if the products were free. you would put up with it. as they are not, should they not work? everything else we buy, is expected too.
            firemouth
          • I think medicine IS more complex...

            aaand it shows. Common, name a drug that doesn't
            have side effects falling off the label! Isn't
            that a bug? The worst part about medicine is we're
            debugging code we didn't write and our interface
            is a sledge hammer. Next gen medicine is bringing
            gene reprogramming. Thing of the bugs we'll have
            then!
            shadfurman
          • re: firemouth

            Really? You ever never buy something that
            breaks soon after you buy it? At least you can
            reinstall your OS. I went through 12 DVD
            Players under a hundred dollars in less than a
            year before I bought a $300 one. My friends buy
            brand new cars cause they hate paying more than
            the value of the car to have it fixed. Almost
            all of them have had their cars in the shop for
            some issue within the first year, guess what,
            it costs more to fix new cars. The world trade
            center was designed to withstand impacts from
            planes... hmmm must have been a bug there!

            There really ISN'T many things as complex. I
            ALWAYS think something I am going to code is
            going to be easy. It never is, and I rarely
            work with code more than a few thousand lines
            long. Windows is more than 50 MILLION lines of
            code. There is not a single developer in all of
            Microsoft that knows every single line of code.
            There probably isn't a developer that knows
            every subroutine or function call, and a bug
            can span many. You can read over a bug hundreds
            of times and not see it. Your debugging
            software can be mislocating the bug. And a bug
            might not crop up unless you happen to type '0'
            into a box your supposed to type your annual
            salary, while listening to bon jovi and
            repeatedly clicking the mouse in rhythm. And
            even though it's pretty much impossible for
            that to crop up under testing, you'd be surprised how often it happens when you have
            100million people using your software whenever
            their computer is on.
            shadfurman
          • @zkiwi... has a point

            Look at it this way.
            An entire OS loaded with software is many thousands, if not millions of lines of code interacting with each other in ways that are so complex that is almost impossible to predict exactly how they will interact with each other.
            If we run a system this this complex then the law of averages states there's always going to be a certain percentage of flawed code.
            The more complexity there is to a machine the more there is to go wrong.

            Another reason its impossible to not have flawed code is that at the speed that technology is currently moving new software needs to be built and shipped out quickly or risk becoming obsolete before it reaches consumers. If we wanted perfect software the entire IT industry would have to slow down to accommodate. This is inconceivable since the growth of IT is exponential.

            Perhaps this means that as technology grows faster there will be even less time for developers and software will get worse.
            lachgil
          • Software IS a special case zkiwi

            There is an old question in software circles: "Why can't we build software like we build bridges?" Hardly anyone gets a bridge wrong or "buggy" these days. Why can't we do the same.

            The partial answer is that a bridge is a much simpler problem, and it is one that has been solved many many times before so there is a great deal of prior art to look at. A great deal of money still goes into bridge design though, because the cost of a "bug" is very high. A bridge going down could cost hundreds or thousands of lives.

            In most cases of software the problem is the opposite. It is a very complex problem, that has probably not been solved before (that you can look at anyway), and the cost of a bug is vastly smaller.

            There are examples of near-perfect code out there. The computers that run car engines or stealth bombers for example. But the cost per line of code is very high and the problem domain fairly small.

            As a general rule, the cost per line of code increases exponentially once you start closing in on perfection. The development cost of making a truly bug-free windows 7 would probably the in the same ball park as the GDP of the entire US. How much are you willing to pay? Not that much? Now you know why there are bugs in code.
            SlithyTove
          • Software like bridges is a fundamentally wrong argument

            The question "Why we cannot build software like we build bridges?"
            assumes a deep over-simplification of the problem of building
            software.

            The question falls in a basic assumption. Physics laws.
            Construction of bridges have them, have always have them, and they
            have always been the same (2000+ years of accumulated knowledge).
            Further more, the users experience them inside and outside the
            bridges.

            Software does not have to comply with physics laws. Sure there are
            performance and constrains imposed by the hardware. But in the
            strict software sense, one can put a menu bar on top of a window
            and it will not fall down, nor need to be hold by any other
            element. And only 50+ years of knowledge.

            This is so simple and basic that we think of it as a ridiculous
            reason to look at, and we ignore it. But it is a huge wedge in
            between bridges and software construction methodologies.

            User requirements:
            Bridges: We better let a qualified engineer to tell us what can be
            done. He knows how to calculate the structure so it works.

            Software: We better tell the guy that read "Programming C++ in 24
            hours." exactly what we dreamed last night, most of the time even
            ignoring technically embarrassing requests (recently I read about
            a guy that was worry that the printer will print hyper links
            because the user might want to click them)

            Design:
            Bridges: This is what can be done, this is were can be done, and
            these are the exact materials that will need. And we might be able
            to negotiate some aspects of it, but you cannot negotiate nature
            laws. Period. (Sorry, cannot put the foundation on sand and expect
            it to support tons of weight for the next 100 years)

            Software: Design??? You mean the sketches of requirements that you
            gave me, which are incomplete? And no point to complete them,
            because as you go using the system, you will discover new
            requirements that you didn't think before. Better yet, lets go
            agile! (try to build a bridge with agile methodologies)

            Development:
            Bridges: Well planned, knows exactly how the foundation has to
            work and were to put it, everything was measure before hand. And
            there is no expectation to try to use the bridge yet, because it
            does not makes sense. Construction crew is working, leave them
            alone.

            Software: Well... I would like to see a mock up of the screen, to
            have a feeling of how it will work... since the mock up is already
            working, why you want to spend my money tossing it away and
            creating a "real system". I'll just use this one that already
            works. Or better yet, you really don't need a database server, I
            have been doing my calculations in excel all these years, just
            look how well organized my folder structures are. You see? it
            works! Just make it work with more data, that is all. What do you
            mean it can't be done? I though you were the expert!

            And of course I can keep going...

            The fact that there are physical constrains in bridge building
            known by everybody, forces construction projects to work within
            those constrains.

            The fact that there are no physical constrains (beyond hardware
            limitations) in software construction, and the constrains of
            software development are very little known even by programmers,
            allows all parties to ignore them.

            Asking "Why you cannot build software like we build bridges?" is
            such gross oversimplification.

            I have a friend that is a construction engineer, and he was
            looking down to my programmer career because he had write a few
            excel macros. Then I showed him how I change the flooring in my
            bedroom all by my self, and that I was going to take on commercial
            buildings designs (his trade), because after all it is the same
            thing only with more materials, right? He felt offended, but got
            the point.
            jorgeleo
          • Hope for the best, prepare for the worste

            Bug free code should always be the goal. Yes time and budget constraints must be taking into account, but the attitude of trying to be bug free should drive all software developers.

            What Windows really needs is some feature cuts and backwards compatibility cuts. With that, more bugs could be addressed and fewer would arise. Windows as is, is too complex for Microsoft to manage as their poor results with bugs demonstrates.

            As for the cuts, there are plenty of features that no one will miss.
            T1Oracle
          • Pithy statements

            [i]Bug free code should always be the goal. Yes time and budget constraints must be taking into account, [b]but the attitude of trying to be bug free should drive all software developers[/b].[/i]

            So you admit that saying you are striving for bug free code is just a pithy statement meant only to drive developers. The moment you brought up "time and budget constraints", you admitted that writing bug free code was [b]not[/b] the goal. It would be like saying [i]my goal is to win the Boston marathon but my training constraints are that I don't want to train more than once a week.[/i]

            Saying that you are striving for bug free code while admitting that you won't actually do it due to time and budget constraints makes your statement nothing more than a "feel good" statement with nothing behind it and only the most naive would fall for it.
            NonZealot
          • Thats like saying we should end world hunger while typing on your computer.

            Such idealism is retarded. If your that
            idealistic YOU should be doing more. If the
            problem isn't fixed yet YOU should go fix it
            instead of complaining.

            Of course as soon as you actually tried to do
            it instead of bitching you would realize just
            how steep the uphill battle is. You have to
            draw the line somewhere, whether its
            healthcare, world hunger or source code.
            NOTHING is perfect.
            shadfurman
          • I fell for it!

            @Nonzealot I fell for it his statement too, until I read yours. But I don't think his intent was to write a feel good statement. I agree with the rest your statement though.
            mathcreative
          • yes but!

            I do think Windows needs more backwards
            compatibility cuts. But problems with
            compatibility was one of the reasons Vista
            flopped so bad. (not the only reason, but I
            remember there being quite a few complaints) To
            cut compatibility Microsoft is going to have to
            cut them one by one a release at a time.

            I really don't know why windows doesnt just
            make every previous version of windows
            available to virtualize in the case of
            incompatibility. A couple of months ago I
            downloaded every major release of windows since
            1.0 just for nostalgia sake and I gotta say
            it's awesome to be able to go back and play
            some of those 16bit windows games. Just cause I
            can. Of course this is technically illegal,
            which REALLY is stupid. Is Microsoft really
            going to lose money on declaring XP
            abandonware? Its not like just cause they're
            stopping support people can't use it. And
            imagine the improvement in windows image! That
            would get a LOT of smiles and forgiveness.
            shadfurman
        • So your saying...

          that MS could be the one to do it?
          Snarfiorix