seedofonan

Alright, I'm considering this hypothetical bicycle, go on ... Uh ... what handle bars?

Which like we said from the start is mostly inaccurate. You can enable PAE, but the ONLY thing that changes is that special apps such as SQL Server could use the extra RAM, and for data only. It DOESN'T make your everyday apps make use of 4GB+, and as such it's not just not a solution to the problem (besides not solving other issues and limitations). BoardBabe never said anything about what 'problem' she may or may not have been interested in solving. What you say is inaccurate -- that enabling PAE in 32-bit Vista (it is by default) will let special apps such as SQL Server use the extra RAM. In fact the Vista 32-bit kernel (software) prevents that. And beyond that failing, neither can two separate apps both allocate 3GB a piece. For either of those scenarios to work, one would have to pay Microsoft $1000's of dollars for a high-end 32-bit Sever edition of Windows, because they do not include the software limitation in the kernel to which BoardBabe is refering. Which are the very same limitations we've been discussing from the very start. Yeah, others need to work on their reading comprehension... lol, now you're among the 'others'. and using chunks from an older kernel into Win 7 is unlikely to work (Vista and Win 2008 use the same codebase, so it's not surprising bits and pieces can be mixed). Obviously. But the original question remains -- will an analagous mixing of same-codebase kernels between high-end server and desktop versions of Windows 7 still get around this software limitation like BoardBabe claims it does with Vista/Server08, or did Microsoft put the kibosh on that?

Reading plainly what BoardBabe has actually written, I contend that the limitation to which he is refering is this one: Physical Memory Limits for Windows Releases and not some other random limitation like the largest pickel that he can swallow or the 4GB virtual memory limit in processes for all editions of 32-bit windows or the reading comprehention of cluberti. So, for example, suppose I have a motherboard with 16GB of physical ram installed. With Vista 32-bit, if you add the total physical ram allocated to each of the running processes, it will never total more than 4GB, even though PAE is enabled. On the other hand, Server 2003 enterprise will, for example, allocate 3GB of the RAM to one process and a totally different 3GB to another process, and so on with additional processes until all 16GB of motherboard ram is in use. BoardBabe claims that this limitation can be gotten around in the case of Vista 32-bit by grabbing some files out of Server 2008 (after cautioning its legality): Finally he asks: And as I said, noone in this thread has addressed either his claim or his question.

I got started reading this forum because of the excellent nLite utility. I have avoided Vista because it is such a f***ing pig, no matter how hard you vLite it. And then I read the news about a research project inside Microsoft dubed 'Min Win' that was successful enough to make an impact upstream into the Windows 7 codebase (and I think even Windows Server 2008 some). I would actually consider buying another Windows OS if in fact it is at least as strip-downable as XP was with nLite. Has anyone heard of anyone trying to get at a really-ultra-stripped-down Windows 7? Or even heard that nuhi is working on, say, n7ite?

Yes, definitly leave your 'explainations' (ie biased opinions) to correct documentation, like Russinovich sure, or even more obvious, wikipedia. I think your sticky about this should simply have linked to such sources. Actually, I don't get why people first ask some well meaning hack these kinds of questions when the internet lets you get it straight from the experts instantly -- no waiting for a reply, elegantly explained, and largely unbiased. To each their own, I guess. I think the industry (chip and os architects) screwed up and now everyone is left with two less-than-ideal options: 32bit/PAE or AMD64. Ideal would be a design that doesn't force the native integer size (data) to have the same number of bits as an address. And why, to maintain pre-ANSI C compatability? Honestly, compared with all the other marvelously intricate capabilities built into moden processors, compilers, and operating systems, this obvious separation would have been trivial to achieve. What are we going to have next, 128 or 256 bit addresses further bloating our code with useless zeros because the processor just happens to have 128 or 256 bit general-purpose registers inside and a few apps would like to take advantage of them for very-long-integer calculations? *puke* And no-one tried to answer the original question, which I think is of interest -- I too would like a way to get around the Microsoft-jerkoff-disabling of access to all of my motherboard ram unless I give them $1000's for (essentially) the same 32bit OS but with the word 'Server' in the name.

I didn't even notice and I have no idea what got me there (maybe load-balancing server pool business?). I looked into that link, DNS points to 207.46.192.254, which in turn reverse-looks back to microsoft.com, not Savvis. Or at least that is where it goes today. Who can tell what it did last week, I'm now forced to wonder, because... That page (and the one without the .nsatc.net, I tried both just now) today downloads a different file with a different filename (now it has a 'IE7-' prefix). The good news is that this new file's content exactly matches the 'good stuff' I got last week the hard way from 'SoftwareDistribution\Download'. In other words, my problem is no more. I tried to see what I get using HFNETCHK, but the only version I could find to install is an old free version. When I run it, it downloads a mssecure.xml that is empty other than the message "This file is no longer supported. Please see http://forum.shavlik.com/viewtopic.php?t=4155". In other words, I am still waiting your precious time with my bozo. ;-)

I'm struggling with the same problem with KB956390 from: http://www.microsoft.com.nsatc.net/downloa...;displaylang=en I've attached its log file. What I've found is that when I let WU run normally after XP x64 has finished installing, WU downloads a totally different set of files than are contained in the one above. What few dlls they do have in common are completely different versions. Specifically, all the SP2QFE/GDR dll versions from above are 6.3.3790.4357 built 2008/08/20 versus the latter 7.0.6000.16735 built 2008/10/04. I'm going to try taking the latter version from SoftwareDistribution\Download and make a self-extracting exe to run during install. But what gives? I'd much rather use a MS download. Anyone know where I can get the right KB956390 for xp x64?