MrCobra

Thanks. I thought i read that it would help somewhat due to fragmentation. Time to use Vista's nifty Disk management to squeeze out maybe a 3-4gb partition on the 2nd 7200rpm sata drive (back up first). Some recommend leaving a very small pagefile on the C drive in case of a memory dump, if the 2nd drive is not available. You can bypass fragmentation on the boot drive, no matter the pagefile size, if you set the min and max values the same. It works best if it's on the 1st partition; faster access. This would be the first thing that i would fix, sure it might be working right, but having ram running at different frequencies in the machine with play havoc with I/O for the machine. try taking the slower 533 ram and see if that helps. best option would be to pick up a 800 mhz 2 gig or 4 gig pack of memory (2 at the minimun!) They won't run at different speeds.

Moving the pagefile only helps if it's moved to a different drive. If it's still on the same physical drive as your boot drive, you gain nothing.

This has been claimed in the past, but never proven. Since the Win32 API has a lot more than Win3.1.x' API, this doesn't seem likely at all. Look at the USER32.DLL, SHELL32.DLL, GDI32.DLL, ect. They are nothing but stubs that thunk into the 16bit layers. The 16bit code is what provides the functionality of the 9x line. Anyone that can look inside of files like those can see it for themselves. Anyone can install SoftIce and follow tracing/debug tutorials and see it as well.

Okay, you don't know what you're talking about, and got this from popular culture. Win9x is not a shell. It's actually a marriage of DOS and Windows, pretty much. The 32bit interfaces in the 9x line are just nothing more than thunking layers that go back down into the 16bit APIs from Win 3.1x, which for the majority of tasks gets shunted back into V86 mode of the underlying DOS and then back into the 16bit API of Windows and ultimately the 32bit layers. As someone else posted, remove DOS from those, and Windows will not operate. Anyone running 9x can trace everything with SoftIce and see the chain of sequences. Trace long enough and you're plopped right back into good ol' DOS code. I personally prefer an NT system and I couldn't use 9x if I wanted to as there's no support for my H/W. I feel NT is far better, but I don't begrudge anyone for using what they want. To each their own.

The question was about XP, not Vista. Specifically, the OP asked if it was possible to swap keys to avoid a reinstall.

No, you cannot reassign D as C and have it work. If there is a tool to accomplish such a thing, I have never seen it. To avoid this problem in the future... Have only one primary partition. Create your OS partition the size you need/want and then create an extended partition to cover the rest of the drive and then create logical partitions in that. Do the same with your other drive(s).

They do work with Vista. With the modified drivers everything works. Creative just doesn't want them to as they're trying to force a H/W upgrade to the X-Fi 2. @OP: Search for daniel_k drivers.

Those errors usually show up with bad CD/DVD burns and/or dirty and corrupted discs.

Uhm, that was not even related to what was originally asked. OP: This is what I found during a quick search. I hope it helps you. http://www.petri.co.il/change_the_serial_in_windows_xp.htm

I get 403 forbidden when i try to download this link, is there a user/pass for it? You can always get the FREE edition of Acronis True Image. Info here. http://help.lockergnome.com/general/Acroni...opict54543.html

NOD32 along with ThreatFire.

Maybe this can help?? Be advised that just changing the fonts in the registry will not always display things correctly. A lot of the dialogs embedded in various DLLs have hard coded values for the original fonts (ex., the RGB color picker input boxes) and will truncate the substitued fonts. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes] "MS Shell Dlg 2"="Segoe UI" "MS Shell Dlg"="Segoe UI" "Helv"="Segoe UI" "MS Sans Serif 8,10,12,14,18,24"="Segoe UI" "MS Serif 8,10,12,14,18,24"="Segoe UI" "MS Sans Serif"="Segoe UI" "System"="Segoe UI" "Microsoft Sans Serif"="Segoe UI" "Tahoma"="Segoe UI" "MS Serif"="Segoe UI" "Times New Roman"="Segoe UI" "Times"="Segoe UI" "Small Fonts"="Segoe UI" "Tms Rmn"="Segoe UI" "Arial"="Segoe UI" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts] "Arial (TrueType)"="segoeui.ttf" "Arial Italic (TrueType)"="segoeuii.ttf" "Arial Bold (TrueType)"="segoeuib.ttf" "Arial Bold Italic (TrueType)"="segoeuiz.ttf" "Times New Roman (TrueType)"="segoeui.ttf" "Times New Roman Italic (TrueType)"="segoeuii.ttf" "Times New Roman Bold (TrueType)"="segoeuib.ttf" "Times New Roman Bold Italic (TrueType)"="segoeuiz.ttf" "Tahoma (TrueType)"="segoeui.ttf" "Tahoma Bold (TrueType)"="segoeuib.ttf" "Microsoft Sans Serif (TrueType)"="segoeui.ttf" "MS Sans Serif 8,10,12,14,18,24 (VGA res)"="segoeui.ttf" "MS Serif 8,10,12,14,18,24 (VGA res)"="segoeui.ttf" [HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\Shell\MuiCache] "@themeui.dll,-2037"="{Segoe UI, 8 pt}" "@themeui.dll,-2038"="{Segoe UI, 8 pt}" "@themeui.dll,-2039"="{Segoe UI, 8 pt}" "@themeui.dll,-2040"="{Segoe UI, 8 pt}" "@themeui.dll,-2041"="{Segoe UI, 8 pt}" "@themeui.dll,-2042"="{Segoe UI, 8 pt}" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontMapper\FamilyDefaults] "Swiss"="Segoe UI" "Roman"="Segoe UI"

Yes you can. It can also be made to be a fully fuctional and bootable OS from a CD or USB stick. There are guides for getting XPe running in Vmware (need a physical partition) and tranferring it to a live system or to a CD/USB. http://www.colin-uk.com/stuff/XPeArticle.zip That contains a word document with all necessary instructions.

I won't use or purchase DDR3 until Nehalem is out on the consumer market.

NVIDIA, No, GeForce 9800. I started using NVIDIA cards when the original GeForce came out. I had used a couple of ATi cards before that and had a really horrible experience with them. I switched to a Voodoo 2 setup after the ATi cards. Went with the GeForce after that. I've been an NVIDIA customer ever since. It's what I prefer.

You might find it strange that I'd spend that much on a MB and not O/C. But I don't O/C any piece of H/W that I own. I generally find, but not always, that the more expensive MBs have greater stability. They are designed for O/C'ing and need to be stable for it and it would make sense that it would be more stable at stock speeds. I don't use SLI either. I have multiple video cards so I can use more monitors. I currently have 3 LCDs and I'm planning on a 4th. I love the screen space. I write a lot of code, dabble in 3D modeling and animation, semi-pro photography, ect. It's nice to be working in an application and watching a tutorial video on how to do something without having to tab in and out. I like to build high end machines. I build one super high end machine about every 3 years and upgrade parts here and there as needed.

From a cold start it takes around 1 minute until the desktop is ready.

On every build, the motherboard without a doubt. Last one was $369. The only other expensive parts I have purchased for my current build was 3 24" BenQ FP241W LCD screens and Ergotron mounting arms for them.

^ Yeah like the pirates have to worry about it. There are those of us that do purchase our software that get affected negatively by WGA.

Well, apparently it is. This link http://www.msfn.org/board/Ultimate-DOS-Gam...sk-t120777.html contains a download for a DOS boot disc that includes MSFT files, which I'm pretty sure permission to distribute wasn't given. The same rules should apply to everyone and not those that you wish to pick and choose from.

I'm sure a lot of people would be willing to pay for a faster cleaned up Windows. I would. That's what it really comes down to. Yes, everything could be hand-optimized asm. But the development costs would spike incredibly. Nowadays, all developers are dead-set against premature optimization (profile, then optimize the parts that actually need it). I never said everything and what I provided was only an example. There are key parts in the kernel and the driver systems that are not optimal. Try disassembling them and have a look. In other parts of the OS the "optimizing" compiler didn't do a very good job optimizing. Sloppy code = slow code. There are ways to trick a C/C++ compiler in to creating a more efficient compiled version of a routine. The second version is also a lot more complex than not only the first, but MUCH more than the C or C++ version. You'd need to hire a LOT of asm gurus to optimize everything like that too, and that doesn't come for free (like cluberti said). Plus, higher LoC count usually means more bugs, hence higher maintenance costs and all that. And there is far more to it than just that! You'd have your i386-hand optimized version, then your other code paths for different processor capabilities (e.g. your SSE2 version of that) plus processor feature detection and such all over the place, so now you're maintaining like 6 different code paths, which are each 50x longer than the original (so like 300x more code), which took a LOT longer to write, likely contains more bugs, and takes more time to maintain, etc. The project very quickly becomes a even bigger monster, which makes it that much more difficult to manage. By using an exception handler to detect if SSE2 support is there takes 7 lines of code in C++. There really only needs to be 2 functions for those routines that could benefit from the optimizations, one for a normal routine and one for the optimized routine. The way around one doesn't have to interfere with the other. The OS could detect is SSE2 is present and if so arrange some internal tables (as it does already) to point to the optimized versions. And just like now with Windows, when you call a routine from your program, it calls to a pointer that holds the location of the routine you're calling. No difference with optimized routines either. The Intel C++ compiler does exactly that when it calls routines within its library. I would argue that if MSFT were to clean up some of the "optimizations" that the compiler produces, foregoing any further optimizing, it would reduce the size of routines and allow for a small increase in execution speeds. Ok, so your codecs are highly optimized and the drivers that Nvidia/ATI have are as well, but the part of the OS that allows it all to work together is full of unoptimal code (have a look) that causes register stalls, branching problems and cache misses which effectively causes the CPU to take longer to get the job done, then those highly optimized codecs aren't doing the job as fast and as efficiently as possible. The same functionality is already there. Go to Control Panel > Programs and Features > "Turn Windows features on or off". So, in Vista I can totally & completely remove Aero, Windows Mail, Media player, Indexing and Search, and others just like in server 2008? Not a chance. In server I can choose to install the desktop experience pack and if I don't like it I can remove it. There's absolutely no trace of it left. Same with the indexing and search. The whole point in choosing what to install is so that those things that aren't wanted/need never get installed in the 1st place.

I think if they can provide the abaility to add/remove features from the Server OS then there should be those same capabilities in the consumer editions as well.

I use XP64 because I want to. I really tried to like Vista. I really tried to like Vista SP1. But there are still lots of problems with that OS. XP may be 7 years old, but it's stable and fast. Vista to me is just too "meh". Even with Vista SP1 it can still takes ages to copy files. I'm still not too keen on the out of memory while copying files bug that's still lurking around. It seems that they moved stuff around just for the sake of moving it. I don't like: The constant thrashing of the HD. All the graphical glitches in the theme. Losing performance in 3D apps because of Aero. The blatant bugs that are classes as 'won't be fixed' that shouldn't have been there at RTM, let alone SP1. Nothing in that OS is consistent. My H/W is way more than capable of running Vista, but it does feel too sluggish (to me). I was not impressed with the OS and there was no WOW factor for me.

I would agree only with "less lines of machine code in a given execution path (i.e. disregarding exception handling code) would run faster than a larger number of lines in the same path" and "more lines of (source or machine) code increases the risk of introducing bugs". Hhowever, the (security, stability, extra feature) benefits of the changes/extensions to code (IMO) outweigh the potential performance hit and risk of bugs (as the internal, alpha and beta testing phases before the release candidates will identify and nail the vast majority of the bugs anyway). Here's an example. If I have misunderstood you then I apologize. Here's 2 versions of the same code. The 1st one is small. strlen: xor eax, eax mov ecx, [esp+4] ; get the string cmp byte ptr [ecx], 0; is end of string? je @2 ; yes then exit @1: inc eax ; inc count cmp byte ptr [ecx+eax], 0; is end of string? jne @1 ; nope, go again @2: ret 2nd version, although bigger, executes quicker. strlen: push ebx mov ecx, [esp+8] ; get pointer to string mov eax, ecx ; copy pointer and ecx, 3 ; lower 2 bits of address, check alignment jz L2 ; string is aligned by 4. Go to loop and eax, -4 ; align pointer by 4 mov ebx, [eax] ; read from nearest preceding boundary shl ecx, 3 ; mul by 8 = displacement in bits mov edx, -1 shl edx, cl ; make byte mask not edx ; mask = 0FFH for false bytes or ebx, edx ; mask out false bytes ; check first four bytes for zero lea ecx, [ebx-01010101H] ; subtract 1 from each byte not ebx ; invert all bytes and ecx, ebx ; and these two and ecx, 80808080H ; test all sign bits jnz L3 ; zero-byte found ; Main loop, read 4 bytes aligned L1: add eax, 4 ; increment pointer by 4 L2: mov ebx, [eax] ; read 4 bytes of string lea ecx, [ebx-01010101H] ; subtract 1 from each byte not ebx ; invert all bytes and ecx, ebx ; and these two and ecx, 80808080H ; test all sign bits jz L1 ; no zero bytes, continue loop L3: bsf ecx, ecx ; find right-most 1-bit shr ecx, 3 ; divide by 8 = byte index sub eax, [esp+8] ; subtract start address add eax, ecx ; add index to byte pop ebx ret The strlen example may not seem like a big deal to most, and it may well not be, but when dealing with lots of data, as most programs do, then the small version becomes a bottleneck. The second version operates quicker. I also have an SSE2 example that's even faster than the 2nd. A lot of the userland functions in Windows are compiled C/C++ code that doesn't translate to very well optimized code. The compiler in most cases produces some nasty code and there are very few specific optimizations in the WIN32 API. I know this isn't 20 years ago and the meticulous optimization practices that were onced used don't need to be used on every single piece of code. But for those routines that are executed over and over, some form of manual optimization needs to be done. Just because CPUs are in the Ghz range doesn't mean code can't be a bottleneck. It would be nice if MSFT would take Windows and just do a major optimization and tweaking to the underlying code. I'd rather have a fast more stable version than one with yet more "features" and greater inefficency. +1

One issue that I have with Windows in general is that it's not optimized. It's more or less a blended mode where it runs on pretty much everything, but it could stand to have highly optimized specific parts to it. There was once a time when programmers actually cared about optimal performance from code. But it seems that in today's world of computers that fast machines=unoptimized code. In response to the bolded part... I've seen code that is pretty big that takes into account the register pairing and chache predictions execute quicker than small chunks of code. Smaller code is not always better.