Slashdot Mirror
A Quick Look at Longhorn Build 4053
An anonymous reader writes "Even though the next generation Windows product is not due until late 2005 or even 2006, here is a look at what Microsoft has in store for it's future operating system. 'Without a vast amount of tweaking, this build is a resource hog. At idle, with no applications running, the commit charge is at a whopping 483 MB!! Obviously, the final release or even the beta releases will not consume this much of the system resources.'"
Actually the amount of RAM put in consumer-level machines hasn't increased that much. It is quite common to see a P4 with 2.4Ghz and only 256MB RAM in the stores. And this amount has been quite stable (more or less) over the past few years.
So the 2006 consumer-machines might habe 512MB of RAM. But if 483 are needed just for Windows not much is left..
Well, NT4 is build 1372 (I think), and I believe that Win2k is in the build number 2000-something... It seems to be the build number for the NT kernel itself.
There are only 10 kinds of people in this world... those who understand binary and those who don't
I found a handy page on Google with some torrents and other doodads. You may want to check how much RAM you have first ;-)
Posted by Team Flexbeta on 05 March 2004 (34135 views) Rating: 4.64
Even though the next generation Windows product is not due until late 2005 or even 2006, we wanted to take a look at what Microsoft has in store for us. We take a quick look at the recently leaked Longhorn Build 4053.
For those of you that are lucky enough to have snagged a copy, remember this, Build 4053 is still a baby, not even in Beta stage yet, so we will not go in depth into subjects such as the theme, sidebar, etc.
The installation wizard has improved greatly from past installers that Windows 2000 and XP had. No more will we see the plain DOS like setup screen, its all graphical now with minimal questions during the installation process, which, has its good and its bad. For a home user upgrading to Longhorn, the installation is a breeze, start the setup, enter the key and go take a nap, by the time you wake up it will be done. If the setup continues on this path towards final release, then the use of an answer file will be necessary to alleviate any post installation changes, especially for a network administrator implementing a company wide roll out, but Microsoft has always provided excellent administrator tools for this very reason. The installation did take an awfully long time, especially during the "Hardware Detection" phase, but I'm sure that this will be improved upon in the months to come.
Even though the initial startup is extremely fast, once logged in the system crawls along, taking a seemingly endless amount of time to get everything up and running. This too will definitely improve over development time.
The layout is clean and clutter free. Minimal icons are presented on the desktop, which is one of my pet peeves; I go to great lengths to maintain an icon-less desktop. The sidebar is definitely going to have its share of protestors, me being one of them. To me, no matter what is docked on the sidebar in the final release, it is a huge waste of space and system resources that a vast majority of users will just turn off. There will be more applets applied to it in the end, search bars, link bars, etc, so as the sidebar comes of age, we will examine it once again.
Without a vast amount of tweaking, this build is a resource hog. At idle, with no applications running, the commit charge is at a whopping 483 MB!! Obviously, the final release or even the beta releases will not consume this much of the system resources. My test system is an Intel Pentium 4 2.4Ghz with 512 MB of RAM, so it is still running at a good pace, but anything less than this makes the system crawl along at an insanely annoying pace. When the final build is released, the recommended system requirements will be roughly the same as Windows XP, but as anyone that has tried to run XP with multiple users will testify, simply having the recommended requirements is just not enough.
At this point in time, build 4053 is basically Windows XP with a different theme, even though some new technologies are being created and there are dribs and drabs of them in this build. Build 4053 is still a lot different from previous builds where some of the new technologies Microsoft is working on were clearly integrated, such as the Hardware Carousel, WinFS, etc, in this build like Build 4051 (PDC) they are absent or implemented at a minimum.
There are very visible bugs at this stage, but it seems that some of the major pains that plagued previous builds have been worked on or corrected. The infamous Internet Explorer memory leak seems to have disappeared, and that was a huge memory leak, but as I sit here writing this, the commit charge is growing and growing, so there are still memory leaks in some processes and/or services that are running.
Some features previewed in previous builds have been developed to a greater extent such as Contacts, Photos and Videos. The layout and orientation of the windows has been vastly improved. All links and graphical elements have been fine tuned
Linux does NOT take that much RAM. Not even close. I'm guessing you're looking at the total memory usage, including cache. Linux aggressively uses free RAM as disk cache, so it will usually appear that most of your RAM is in use.
I have run Kernel 2.6.2 on a 486 with 16MB RAM. It wasn't doing a lot, mind you, but it had a few megs free. (It was NOT running X.)
Its not always a bad thing to have memory in use. In fact, Linux aggressively tries to make use of every piece of memory it can. If you haven't used an application for awhile it will page it into swap and reclaim some RAM for the file cache or other programs.
The other thing to be careful of is top and other memory reporting utilities report X as taking up far more RAM than it actually uses. This is because X mmaps your video card memory. So if you had 128 megs of video RAM, your X would look pretty huge.
The more you know, the less you understand.
That build number is the build of the overall NT kernel and code branch, not just of Longhorn. For example:
Windows NT 3.1 = build 511
Windows NT 3.5 = build 887
Windows NT 3.51 = build 1057
Windows NT 4.0 = build 1381
Windows 2000 = build 2195
Windows XP = build 2600
Windows Server 2003 = build 3790
(FYI, those are for the original release versions. Betas have earlier build numbers.)
Longhorn 4053 Tweak Guide ...
...
Found this over at Neowin
Yeah, but most of the stuff in the kernel.debug binary is just debug symbols -- they live in the file but aren't loaded into memory. If you compare the two with the 'size' command you'll probably find they're much closer. But this Windows thing apparently (article site is down just now) has 483 meg resident -- which is gigantic, and debug symbols would have no effect on this.
Actually, the NT kernel itself _is_ lean, and contrary to popular Linux fandom theory, the Linux kernel is _not_ lean. The NT kernel supports a bare minimum of functions for interfacing modules, then everything else is written in modules around it, while Linux is monolithic(put a lot of functionality in the kernel itself) and pretty bloated.
This is a myth. NT is not a microkernel, at least not anymore. It was around 3.x (whatever the version number was), but not anymore. IIRC, even the window management functionality is in the kernel now.
And it's not just the kernel - the win32 API is a monster, containing a lot of GUI functionality and whatnot.
Oh well, I guess you should expect nothing less from morons who thought CR/LF, backslash dir seperator and drive letters are good ideas.
Save your wrists today - switch to Dvorak
I don't really know how modern Windows versions stack up in terms of stability. Win98 and earlier releases were horrible, and some people seem determined to pretend it's still like that five years after the fact, but it's been my experience (with a lot of installations) that Windows XP/2k really don't crash much, except for hardware/power problems, and weirdness with third party programs.
Defending Windows on Slashdot is probably asking for bad karma...
Longhorn is a patch over XP.
.NET framework for managed code.
Not really. Windows XP was over 2000 though. There are some huge underlying changes -- not a 100% rewrite -- but some major rewrites anyway. For example is the Windows programming API switched from Win32 to WinFX, and a whole lot retrofitted for the
In total, I'd expect Longhorn to bring about as many rewrites as there was from Windows 3.11 to Windows 95.
Beware: In C++, your friends can see your privates!
At idle, with no applications running, the commit charge is at a whopping 483 MB
This is crap...
Testing both 4051 and 4053, even with all the 'extra features' turned on, the commit charge is around 240mb.
Additionally, there are about 50-100mb of Services for Microsoft reporting that is running and is used ONLY for reporting to internal servers at Microsoft for the developers at Microsoft. And thse services can and should be turned off, since outside testers are NOT using these services.
Some of our developers are running Longhorn in VMWare and VirtualPC with it set to 196mb and 256mb of RAM for the guest OS. And it runs better than expected for a pre-beta.
Let's dog on Longhorn when it gets to RC1, the current Alphas are so far away from the shipping product it isn't even close.
This reminds me of Windows 2000 when it was Beta 1 back in 1997, it was a TOTALLY different OS than even Beta 2 or RC1. Beta 1 of Windows 2000 had very few features working properly and was slow as hell compared to the release version.
Considering the time table of Longhorn, 2 years is a lot of time for a lot optimization and it already has a solid NT core that the redesigned Windows Subsystem will run on.
If all else fails, I would bet money that when longhorn releases it will run as fast as WindowsXP, even on comperable hardware, although you may have to turn off many of the 'resource intense' features of Longhorn to make it run well on lower end hardware.
TheNetAvenger