Will Microsoft LongHorn require 2GB of Ram?

Page 3 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

kylef

Golden Member
Jan 25, 2000
1,430
0
0
Originally posted by: drag
Stuff like how Longhorn is going to use a 'new' kernel and will break much backward compatability with very legacy Windows applications that depend on it and MS is probably going to recommend virtual PC program to get full compatability with those things.
This sounds suspicious to me. I'm not saying it won't happen, I'm just saying I haven't seen anything like it happen (yet) and it would be a significant change in operating policy as far as application compatibility is concerned.

For hardware resources they are aiming for any new PC sold during 2005 will be able to run Longhorn, but probably not be able to run it realy well. Probably much like how Windows XP first came out, I am supposing. His projection for minimal/recommended hardware requirements are 3ghz Pentium 4-level proccessor (or 1.8+ ghz mobile cpu, intel pentium-m style) and 512megs of ram.
Again, I won't claim to know everything that's in store for Windows code-name Longhorn, but I'm running it quite comfortably on an 850 Mhz Duron with 512 megs of RAM at present. My guess is that it will continue to be possible to run on such a system, but many of the newer features will require newer hardware. If you don't enable those newer features, I suspect you'll be fine.

Edit: Keep in mind that the reason Microsoft hasn't announced hard-and-fast requirements yet is that Windows code-named "Longhorn" is still a moving target. Engineering is still taking place; new features are being developed; combinations are still being analyzed. But for cases like operating systems and business applications, software requirements have never traditionally been "hard and fast". They are simply a set of suggestions to safeguard your basic user experience. I would expect the same thing here.
 

timswim78

Diamond Member
Jan 1, 2003
4,330
1
81
Originally posted by: NateSLC
Originally posted by: MrControversial
...at 5400 RPM.

All joking aside, though, I won't be surprised if PC manufacturers start implementing some form of RAID for Longhorn. As you may or may not know, it uses a whole new file system called WinFS that uses a relational database to store files. So you'll be able to query files based on a number of attributes. You can even write custom queries in SQL to query files. WinFS on RAID0 would see a huge performance increase on theory alone.

Why the heck would anyone want to buy Longhorn if there is not WinFS?
WinFS will not make it's debut in Longhorn.

new.com

 

homercles337

Diamond Member
Dec 29, 2004
6,340
3
71
Originally posted by: kylef
Originally posted by: bersl2
[Hey, the only tools I really, really need are find and grep. Everything else is a bonus.
I realize this was intended to be somewhat humorous, but in reality, this is part of the problem with the way people use computers today. The traditional search tools are too slow for frequent searching and too coarse to find the specific content a user wants to find.

We avid computer users are generally well-organized. We comprehend the concept of compartmentalizing our data into "files" which belong to groupings called "folders". We even recognize that the best way to "find" files is to never lose them in the first place, and remember where we put them (i.e., a directory structure). So we don't really understand why this is such a big deal.

But the file/folder abstractions are not obvious to peple who have never used computers before. Such users don't really understand the concept of the file abstraction: they want to think about the content itself. They think about songs. They think about spreadsheets. They think about documents. In other words, they want to think about the content objects they're interacting with, not the files (and support files, backup files, etc) that "contain" that content.

WinFS is a set of services designed to solve these issues with the way content is organized on a PC. It is designed to optimize for frequent searching. It is designed to offer content producers and/or app vendors a mechanism to add rich, structured metadata on top of the traditional filesystem to offer users a better content-centric experience.

Sounds excellent to me!
 

Googer

Lifer
Nov 11, 2004
12,576
7
81
Originally posted by: MrControversial
...at 5400 RPM.

All joking aside, though, I won't be surprised if PC manufacturers start implementing some form of RAID for Longhorn. As you may or may not know, it uses a whole new file system called WinFS that uses a relational database to store files. So you'll be able to query files based on a number of attributes. You can even write custom queries in SQL to query files. WinFS on RAID0 would see a huge performance increase on theory alone.

Microsoft Ditched any plans of including WINfs in the final release of XP64, but it may show up later as part of a service pack.
 

VirtualLarry

No Lifer
Aug 25, 2001
56,571
10,206
126
Originally posted by: kylef
Originally posted by: drag
Stuff like how Longhorn is going to use a 'new' kernel and will break much backward compatability with very legacy Windows applications that depend on it and MS is probably going to recommend virtual PC program to get full compatability with those things.
This sounds suspicious to me. I'm not saying it won't happen, I'm just saying I haven't seen anything like it happen (yet) and it would be a significant change in operating policy as far as application compatibility is concerned.
I think what he is describing, is that to make full use of the new features that the WinFS database-like file storage/API, that existing apps written to use a "normal" hierarchial path-named filesystem API would have to be almost entirely re-written to more deeply integrate with WinFS.

Considering how little MS (apparently) documents the NT Kernal APIs, and how most existing apps are actually Win32-based apps, not NT-based apps, any significant changes to the NT kernel wouldn't even be an issue, as long as the upper levels of the Win32 API that are exported remain the same. Given that, I'm not sure what he's going on about.