cluberti

The code was also far more primitive, and lacked the ability to do a lot of the "wow" that Win7, for instance, can (the fact that the old Windows GUI *couldn't* do a lot was the reason a company like Stardock existed).

Here's what to do - open Process Monitor, enable Boot Logging, and reboot. When you come back up, open Process Monitor, get the prompt, and save out the log file (that's what it was asking you). Then you'll have a .pml file you can open up in Process Monitor to view what happened from kernel load to the time you saved the log.

The problem isn't that it can't be done, it's how complex can the code get and still be supportable? How far do you go? Where's the cutoff point where being customizable becomes too customizable, causing unforseen GUI complications? Not only that, who supports it when it breaks, who maintains the code once the dev group moves on to the next OS project, and how much of this will you have to maintain going forward into the next version?And really, how large is the userbase that wants this versus the folks who'll be fine using it as-is and will never touch the desktop in any meaningful way? How many machines do you have to see still using the default OEM logo for the wallpaper, let alone changing the UI, before realizing that other than a small vocal minority (probably similar in size to those who will complain that the old Win95 classic interface is gone from Win7 too), no one really actually wants this? Also, how much money should be thrown at considering this, mocking up code that'll run, testing it with focus groups and gathering/parsing usability data from beta testers versus the actual return on that investment of making it a feature? I know the idea might be nice, but the realities of the world kind of crash down on it.

Yes, it *is* about *directly* accessing memory addresses above the 4GB range and making them available - directly - via the window mapped out in your process space VA, via VirtualAlloc calls. Yes, yes, yes, yes it is about addressing physical memory. It's the *only* way on a Windows box to do so without writing a kernel mode driver to access (as some RAMDISK drivers do), and with some quite severe restrictions which I've already documented (being marked ReadWrite only, so no executable code, having to do your own memory management of the memory pages in the window, etc). This I have never said. What I have said is: you intermix PAE and AWE, and that is wrong. I'm not debating this with you anymore. You've continuously said that I'm intermingling PAE (as in the PAE kernel) and AWE (as in the AWE API used to map memory above the 4GB boundary via VirtualAlloc calls), and that doing so is wrong, and yet someone who is so knowledgeable of Windows internals would know that on Windows these two are inextricably linked - one does NOT work as designed without the other, period.More specifically, when I asked you specifically to tell me how to use the physical memory above 4GB without loading the PAE kernel or without using the AWE APIs on an x86 Windows system, you turn around and not answer the question but tell me that I'm wrong and that AWE is not about accessing physical memory - when in fact, it *is* about accessing physical memory above the 4GB boundary. So that's strike one. Ultimately, AWE *is* about addressing physical pages of RAM, via virtual memory addresses mapped into the process' VA, via the VirtualAlloc APIs. Two, we're not talking about paging or writing physical RAM pages to a paging file or vice-versa, we're talking about mapping addresses above the 4GB boundary into the 2 or 3GB VA address range of a process calling the AWE APIs to do so. This has little or nothing to do with paging, it's about using the additional 4bits in the CPU to address the additional 32bits in the PTE. You are correct, the process sees a virtual address within it's 2 or 3GB VA, but the process must use the AWE APIs to map memory above 4GB into that window, and it *requires* that a PAE kernel be loaded, or the AWE API calls will work, but simply give you RAM addresses below the 4GB boundary. Since your answers indicate that you seem to think somehow this will magically work without the PAE kernel or AWE APIs on an x86 Windows machine, when in fact these are required, that's strike two. Next, you continuously skirt my questions and respond with statements that show you do not understand this as deeply as you think. I asked a very simple question that for someone who's ever dealt with this should be able to answer quite easily, and you didn't. In fact, you responded with a response that had nothing to do with the question, meaning either you couldn't answer my question, or somehow you didn't understand it. Since I doubt it's the latter, and it's more likely to be the former, that's strike 3. Again, my question was very simple, and failure to provide an answer that would have supported your position makes it obvious to me that for someone who espouses to understand how this works, you do not. Just knowing the hardware side does *not* make you knowledgeable about how this is handled in Windows, and your answers bear out this fact. In Windows, AWE and PAE are inextricably linked, and you should know and understand this. I'm done arguing this with someone who obviously hasn't developed in Windows against the AWE APIs and has maybe just read the Windows Internals book. You have no idea who you're talking to or what my expertise is, but from your answers I can see that you are *not* familiar with AWE or Windows above and beyond the Windows Internals book. [Closed].

Why don't you explain, as a developer, how you would allocate memory above 4GB on an x86 machine without the AWE APIs or the PAE kernel on Windows. I'd love to hear it.

Should be OK just to click OK.

I get those on my system that boots in under 30 seconds. They're quite normal. It would probably be better to run process monitor and enable boot logging to see where the time is going.

Well, it is an nVidia video card. I've never run into any of this with other video cards (even cheapo onboard Intels work), and given nVidia's track record with Vista drivers, I'd say bothering nVidia is probably going to be more fruitful than contacting Microsoft (although I'd still bother them both about it anyway so there's no ambiguity as to what problem(s) exist).

I prefer to ride without handlebars and just go where the bike takes me. It's kind of like "I'm feeling lucky" in a Google search, but with a far bigger impact on the direction of my life. Yay chance!/sarcasm

Here's a question - are you sure your product key is legit, and hasn't been pirated?

You would only need to use the keyboard to dump the machine if it wasn't crashing. Since it is, simply set it to complete memory dump as per the instructions, reboot, and wait for it to crash again. When it does, you'll have the .dmp file we need of the crash.

Agreed, hence why I said: But, again, <x>Lite wasn't designed initially to reduce the size of Windows - it was to remove components and make a way to slipstream things into the original install media. The fact that nuhi's tools were able to trim down the install size of Windows was a side-effect, but not the goal. It will be up to nuhi to decide whether he wants to open it up, continue with it himself, or let it die. All choices are his to make.

What happens if you change to the Windows 7 basic theme?

Well, that depends. I'm also using 32 more registers than I would on 32 bit, and my kernel pools are a lot less constrained (you'll use a greater percentage of your kernel pool on PTEs in x86 than you would in x64, even though the pool allocations are about the same), not to mention that if I have an app that can make use of the memory above 4GB natively (including the OS itself), it makes more sense to use the platform designed for it, not hacked for it. And although it's less of a problem nowadays, you still do have to worry about whether your x86 drivers will work properly on a PAE system vs using x64 drivers on an x64 system. Obvious other benefits are LARGEADDRESSAWARE x86 apps getting up to 4GB VA on an x64 system, or being able to access 64 cores/processing units vs 32 with x86 (although client-side that's probably not an issue for years yet). Also, having greater than 8 GP registers is also a nicety for speed, plus allowing floating point operations to use SSE2 registers vs using the fp registers on x86, making use of fast calls and the ability to send 4 registers as an argument vs push'ing and pop'ing off the stack in x86 for fp, plus in x87 fp is stack-oriented, meaning more stack overhead and somewhat less efficient against the x64 design. At least for Windows, unless you actually absolutely need x86, at this point, I recommend x64. Not just for large memory usage (although it is a plus considering buying 8GB of RAM is fairly cheap nowadays).

Correct, but the post was about moving a whole process VA into memory above 4GB on a non-Windows server OS, and to do so you *have* to have the PAE kernel loaded. AWE doesn't need PAE, it's just an API, but to use the RAM above the 4GB address limit you have to run the PAE kernel in Windows. That was my point. And technically, the overhead of PAE and doing the translation vs just using x64 just doesn't seem worth it unless you absolutely must use something that will not work on an x64 system.

No. Technically, AWE has nothing to do with PAE. It is just a technique for a 32bit app to access very large armounts of RAM, but it is not PAE. Again, you're technically accurate, but missing the point. Yes, AWE is just a way to use VirtualAlloc to do your own memory management. However, without the PAE kernel loaded, the AWE api's cannot access memory over the 4GB address limit. They'll work, mind you, but the ranges they get back from VirtualAlloc will be within the 4GB range.

Correct, otherwise DEP wouldn't work. I'm well aware of it. Correct, processes on a Windows machine only know about VA, not physical addresses, but the memory manager does the translation, and as such it does understand memory addresses AND VA. AWE is the API set used to access PAE memory. And technically, you are correct, you don't need /PAE to use AWE, but without /PAE (or running an OS that doesn't automatically enable PAE by default), you won't load the PAE kernel without /PAE. Thus your AWE calls *won't* be allocating memory above 4GB (it's just an API - it doesn't *require* PAE to work, but it *does* require PAE to access memory above 4GB, requiring the PAE kernel to do so, thus *requiring* PAE if you want it to do what it was actually designed to do: True, but if you want that physical memory location to be *above* 4GB, you need the OS to load the PAE kernel, hence the need for /PAE. Also, due to limitations on the client and lower-end server OSes, you also need that OS to be an Enterprise or higher version of a Windows Server OS as well. Really? Because Microsoft says otherwise:

I would install all updates except SP3, and reboot. Assuming the machine still works, download SP3 manually from the Microsoft.com site and try to install it that way - just to make sure you don't have a problem with the express package downloaded from Windows Update. That's what I would suggest you do first.

Agreed - considering the add/remove components has morphed into a way to really remove/disable Windows components in Win7, and the fact that it has a command-line interface for it, it might be unnecessary. I know there'll be those who want to trim the size of the install down, but using it to "lighten" the install itself isn't all that necessary with Win7 anymore, you can do it with Win7 directly.

Agreed - Vista tends to be a like it or hate it proposition for XP users. Those stuck on the classic interface, or who have older hardware (less than 2GB RAM or a multicore CPU) also tend to find that XP is better than Vista for their needs, whereas the converse is also usually true. Also note that Windows 7 is going to be out next year, likely, and will be something you might want to consider as well when you are purchasing your new computer.

No worries, and good luck .

Agreed - basically having an A/V, some spyware protection, and a good disk defragmenter is really all you need, but if you want specifics you'll have to be more specific in your post's questions. Too vague, really.

For what it's worth, it looks like this was documented: http://blogs.msdn.com/psssql/archive/2009/...ermination.aspx

For what it's worth, it looks like this was documented: http://blogs.msdn.com/psssql/archive/2009/...ermination.aspx

You could consider using the Microsoft Desktop Deployment Toolkit to help build your unattend and app installers - MDT 2008 is specific to Vista, but if you want to support both Vista and Win7 you can consider the 2010 beta on connect as well. Gives you a nice GUI and a way to create a task layout of all your app installs, and plus it'll inject drivers, etc - all from a GUI. You really don't have to do any xml file editing at all. Just a suggestion.