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.
A new architecture When the development of Longhorn began, the 64-bit processors we know today were not yet available. In 1994 Hewlett Packard partnered with Intel to create a new 64-bit architecture based on an earlier development called “EPIC”.
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:
S: So, when we’re going to get Vista, what are we going to see that is yours?
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.
Bits and bobs Basically, componentising Windows means breaking all of Windows’ features into bits, called components. A feature can be something like WinFS, Internet Explorer, Terminal Services, TCP/IP etc.
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.
A bit of binary to begin with At its core, a computer can only distinguish between two values. A value is either high or low, 1 or 0.
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.
Backstory Up until Longhorn, Microsoft had been creating Windows with hard-coded strings spread throughout the code. This would have not been a big deal if Microsoft planned on releasing only one Windows version with one language option, but it might begin to form a problem when your wish is to change Windows editions (or even the product name) on the fly during the Windows development process and add languages when needed.
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.
In the video “Why I love XAML” on Channel9, published 20 August 2004, Joe Marini shows of an Avalon application powered by data binding, all of which is contained in a single XAML file.
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.
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.
Virtual teams Developing software can be hard.