meowing

Come on, be honest:How often have you actually been *required* to use the shadow copy ability (which is yet another resource heavy indexing system slowing down and constantly monitoring each and every move that has been made in the OS), ever? How often did you encounter a 'problem' that could only be recovered using that shadow copy? I simply have not needed it once in the 17+ years I'm running machines on Win95 or newer operating systems. I already made backups. Which I also extremely rarely needed to use for some type of recovery. At least not often enough to warrant a HUGE space and power hungry shadow copy system to be active ALL the time. I use ERUNT with XP x64 Edition. Which is more than enough for the able computer owner/user to recover 99% of real-life occurring problems one might encounter with current-day hardware. NOT ONCE have I needed more to fix a problem I've encountered regarding the OS. In the 10 years that I'm running ERUNT combined with a rare need of 'SafeMode' startup it has served me just fine. I did not need a Volume Shadow Copy OR System Restore system, ever. I make backups already. Which I never really needed to use, by the way. I might have used a disk backup once, simply because it saved me some time. But I could already solve ALL problems I've ever encountered with ALL Windows-machines I've administered/managed/maintained/used. Which also underlines what I mentioned before: It's not the system, it's the user. If the user is computer-wise, he/she doesn't need Windows to be at the Windows 7 level. The need for Windows 7 therefore doesn't exist in theory, it only exists for stupid (for the lack of a better term) or unexperienced computer owners.

I'm forced to use and admin Win7 for work-related matters, and I assure you: I still get stuff done MUCH faster in XP x64. If anything, Win7 is made for non-computer-savvy users, not for us experts. I strongly dislike the slowing and utterly dumbed down GUI of Win7, which comes out more complex for people like me. It's similar to the GNOME versus others in unix/linux world. It's a difference of philosophy regarding what is important for the user. I don't like systems that don't allow me to look and work under the hood. XP x64 by far STILL outruns my performance tests as well. I don't need fancy 3d interfaces to work with, it's NOT easier or quicker, rather I find that it slows me down while working. I've been using computers ever since the early days, I liked the simplicity of DOS too. I'm 44 years of age, that may have something to do with it. I'm old-school and I use PC's to produce, create and actually admin and DO stuff with. Windows 7 is for those who consume and entertainment purposes only. And even then, I'd much rather edit video on XP64 than on Win7. XP x64 is not slower on new hardware. And is still kept up to date as well.

As I wrote earlier: Cleartype is post-processing of fonts that aren't good to begin with (or they wouldn't require cleartype). It's not something you should rely on, as it is not a reliable standard. Font smoothing is ugly blurring in my eyes. Cleartype never does it the way it should be done, or I prefer hard lines over soft edges. Also, NOT being able to see where it goes wrong in fonts would be my preference over software regulated changes in displaying them.

Any news with the latest nvidia XP x64 release? ( NVIDIA Forceware 263.09 WHQL XP 64 ) Does it work with nLite again?

By the way, a humongous 105 Megabytes(!) for their latest drivers-installer! Is all that crap really necessary? Geez, hope nvidia wakes up and stops forcing those huge packages upon us. I don't know anyone that actually uses all that crap they include.

What are the advantages of HFSLIP x64 over nLite ?

Yeah, all this has NOTHING whatsoever to do with XP x64 Edition. There's another lightweight PDF-reader I can recommend; http://www.stdutility.com/stduviewer.html Works great in XP64.

Try http://www.techmixer.com/download-directx-10-for-windows-xp/

Hmm.. my experience with XP x64 is the opposite of that. It's the fastest OS I have on my multi-booting main system. I had no problems finding drivers for any of the hardware that is in it (including full support for my SSD boot-drive and echoaudio sound-card). As far as I know THE ONLY companies refusing to properly distribute drivers for XP64 are Lenovo and Engenius/Senao. The rest either offers drivers for XP x64 on their websites, or states that their Vista x64 drivers also work for XP x64 (and by golly actually do indeed), or the 32bit drivers work.I will be working in XP x64 Edition for years to come. Pretty sure of that, since it does what I want extremely well and I'm in control of what my OS does all the way. Can't say that about Windows 7 or Vista or any of the Linux or Mac OSX derivates I've been forced to install for certain people or due to software demands. By the way, is it just me or WHERE the hell do I install a font in Win7? And I don't notice a speed improvement with Windows 7 over XP64, so for me there's no reason to 'upgrade'. The best software I use is available for XP Pro x64 and runs fluently. I do most things in XP64 and am a happy camper. Plus, I have an updated install-iso using 5eraph's and other people's packs from the rvmi forum. I have Firefox 3.6 32 bit as well as 64 bit alpha installed on my XP x64 system and both work great separately. Mozilla x64 software does not have all the addons I like (yet) but that's about all I can say that bothers me. I can highly recommend using it. The newer the hardware, the better it works, still. We all use XP64 where I work, it's more reliable and stable than the others. No doubt about it.

LOL, hexediting it in memory is a neat and cool option, but somehow I'd rather do the hex-editing beforehand.Thanks for all the hints. Should all work now.

Just to be sure, you mean: title Loading XP install - plain /XP64/I386/SETUPLDR.BIN chainloader /XP64/I386/SETUPLDR.BINin your layout, correct? And .\XP64\WIN51 .\XP64\WIN51AP .\XP64\WIN51AP.SP2 .\XP64\NTDETECT.COM .\XP64\TXTSETUP.SIF should all still stay there?

That's great! As I understand it, I need mkisofs to create the iso like this: mkisofs -R -b grldr -no-emul-boot -boot-load-size 4 -o grldr.iso iso_root and I read a lot about different versions of mkisofs, is there any version specifically fitting for XP x64 that you are aware of? OK, this is loading the unaltered setupldr.bin location; How would grub4dos work together with your layout as described above in Post #2? I assume nothing changes, except for the setupldr.bin being under /I386/ which needs to be hexedited still, correct?

Leading stads for leadership, the leader, the best, the most used. grub4dos must do the job. Thank you. Yes, grub4dos is also used by the MultibootISOMaker: http://www.911cd.net/forums//index.php?showtopic=23375 but I have no idea (as of yet) how to set that up for a menu to run XP x64 setupldr.bin files.. if you find a decent example, please post it here.

Given cdshell: the Boot Catalog contain a pointer to another sector. This sector contain data from loader.bin. So, I think this means you need to burn cdshell's loader.bin to that sector (as that sector of 2048 bytes), and that loader.bin sector on the iso tells the machine to check the folder /BOOT for the next step? Really strange, but this information on cdshell is not easy to find, so thanks for the Torito pointer. I can only find this http://cdshell.org/doc/loader.html but without examples. By the way, the links to cdshell in most guides are wrong, it's at http://cdshell.org/ now.

Yes, I knew all that, but what binaries are they, how does the booting PC know it should read those, where is this set?

Command does NOT replace all amd64. That was not my question, nor did I make that statement.I know you're making 4 chars from 5 by adding x00. By the way, even though setupldr.bin isn't an executable, it might be safer to use x20 before the x00, see here. I don't see how "Do not replace all occurrences of "amd64" since some of them refer to a section of txtsetup.sif" would not apply to both 'solutions', i.e. I'm NOT mixing any.

But what makes the DVD boot from CD Shell? Is it just the loader.bin in /BOOT that causes this or is it something else?

Is replacing all the amd64 entries as in gsar.exe -i -o "-sAMD64:x5C" "-r%char4%:x5C:x00" %setupldr% gsar.exe -o "-sAMD64:x00" "-r%char4%:x00:x00" %setupldr%really safe? I ask this because of what it says here: "Do not replace all occurrences of "amd64" since some of them refer to a section of txtsetup.sif" When I compare the two setupldr.bin files (the one in that post and the one generated by the gsar commands), the one from geitonaki has a lot more amd64 entries left in there.. :-/ Still not clear what to replace in setupldr.bin and what to leave as is... Can someone reassure me the gsar script here is correct for XP x64 SP2 setup/install?

Just meant an up to date XP x64 image, I have no idea if MS ever updated setupldr.bin post the XP64 SP2 disk release.. BBIE - Bart's Boot Image Extractor http://www.nu2.nu/bbie/ spcmdcon.sys contains the boot image too. At offset 0x17F00, size one CD data sector. Thanks! Is replacing all the amd64 entries as in gsar.exe -i -o "-sAMD64:x5C" "-r%char4%:x5C:x00" %setupldr% gsar.exe -o "-sAMD64:x00" "-r%char4%:x00:x00" %setupldr%really safe? I ask this because of what it says here: http://www.msfn.org/board/solution-multibo...004-t58410.html "Do not replace all occurrences of "amd64" since some of them refer to a section of txtsetup.sif" When I compare the two setupldr.bin files (the one in that post and the one generated by your gsar commands, the one from geitonaki has a lot more amd64 entries left in there.. Still not clear what to replace in setupldr.bin and what to leave as is... Can someone reassure me the gsar script here is correct for XP x64 SP2 setup?

OK, I was under the impression that XP64 isos don't use this anymore.. Is there an easy way to obtain such image from an official XP64 iso without having to use Isobuster?

So are these still valid as the only 4 required changes inside setupldr.bin for XP x64 (SP2+)? And should this be applied to both copies of setupldr.bin per OS (the one in the original location and the one in the os-root) ? Is moving ntdetect.com one folder up simply to get the 4char replacement of i386 working, or is there another reason? If it would be: "\i386\ntdetect.com" -> "\%char4%\i386\ntdetect.com" one would not have to move ntdetect.com in the os-root, right? Thanks!

So if one wants to use cdob's method, what does one use to load the different OS setup folders? He/she forgets to mention that in his 'guide'.I prefer using EasyBoot, because I once paid for that thing. But it's quite unclear to me which files need to be edited how, even when I read this entire thread. The solution posted here involves flyakite's guide, which I think is way overkill for just a couple of XP x64 isos on one DVD.

Hmm.. I'm afraid for XP x64 it's more than changing their installer. I tried this inf change but got the same errors which started this thread.Have you tested the latest one from nvidia in XP x64?

No, I'm using one base core volume for both install isos, so the volume name of the dual-boot DVD should be the same as the original volume-name. I've done this before, it's more efficient to auto find proper drivers and such with the proper volume lable. Thanks for that. I hope it does work with x64, I'll let you know how it works out. To clarify, that's two $OEM$ folders. The root of the dual-boot-installer is not the root of CD.No I mean my $OEM$ folders have the exact same content for both, so I was wondering if I could put only one on the disk, in the root of the DVD, and then somehow point to them from each separate installer. Do you know where the location for that precopy $OEM$ folder is read from during the installation process? I could hexedit if necessary.. OK thank you. You wrote there:"Follow flyakite's tutorial and ignore flyakite's tutorial." so.. which one is it? ;-) What part should I follow from flyakite's tutorial? I prefer using just BCDW. Pity its original developer has disappeared..

As for Boot Sector: follow flyakite's tutorial replace I386 with used 4 char name, remember .\XP64\ directory. that's replace I386 with XP64 This is a little confusing; Gremo calls it Boot Image, you call it Boot Sector. What exactly do you mean here?