If you ever bothered to take a look at one of the 64-bit Longhorn compiles, you may have noticed that most of these builds are extremely empty and lack, as one example, the sidebar. There’s a good reason why these compiles lack lots of features the x86 Longhorn compiles did have.
Here’s just a funny tidbit I found some time ago to keep you guys entertained. In an interview on Channel9, Robert Scoble asks a designer on the Windows team, Jenny Lam some questions about Vista and how its coming up Channel9. During the interview the following comes up on the subject of wallpapers:
At WinHEC 2003 Microsoft revealed that Longhorn would be build from the ground up from a list of components. Already before this time various people at Microsoft had stated that Longhorn would be the first “modular” operating system. What does this all mean? I’ll try my best to get clear what componentising really is.
This quick introduction to hex was originally to be part of another article, but became quite long and therefore I decided to separate it. Even though it doesn’t have anything to do with Longhorn in particular, I believe it will be worth the read.
While exploring Longhorn builds you might have noticed these weird spelling mistakes in the Windows branding like; “onghornLay rofessionalPay” and wondered whether one of the developers had a breakdown while typing this. In this article I will elaborate on the exact purpose of the “onghornLay” branding.
At Microsoft, it is common practice to use products still under development to continue development of that very product. Once a stable version of a product is available, developers are encouraged to install it on their workstations and use it for everyday use. Developers using the product can directly provide feedback and report bugs to teams working on certain features. This process is internally called self-hosting. Often times the process is also referred to as “eating your own dog food” or doogfooding: when the product is no good and tastes nothing better than dog food, developers will still need to eat it.
I’m on some sort of “write down all the things” spree, documenting things I’ve found in the past, but never properly have written down here on longhorn.ms. Today I’d like to have a brief look at this unidentified build.
The newest Windows product at the time of the reset in late 2004 was Windows Server 2003 SP1 RC, which was used as a base after the reset. The new codebase was first componentised before any new features were added to it. Work on componentising the Server 2003 codebase had already begun weeks before build 4093 was compiled. The post-reset range started at build 5000. The first post-reset builds were compiled by the vbl_core lab. The last pre-reset build compiled probably is 4094.private/Lab06_dev_tech(skatari).
Often times people are confused to hear Longhorn was based off of Windows Server 2003. To the newcomer it seems more plausible that it was instead based off of Windows XP because early builds look so much like it. In this post we will have an in-depth look at the early beginning of the Longhorn project. Along the way we will discover how Longhorn emerged from the Server 2003 code base.
Ever looked at a Windows build list and wondered what all those different tags mean? Or did you ever wonder about the production process of Windows? If yes, you’ve just clicked the correct article. This article will elaborate on the Windows build process as used during the pre-reset Longhorn development. Please note that even though I’ve conducted rigorous research, not all information in this article may be accurate.