Jump to content

meowing

Member
  • Posts

    135
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Netherlands

Posts posted by meowing

  1. That was exactly what i was thinking when i remembered that Win7 have the shadow copy ability (which is a lot better than XP restore point) and if you manage the shadow copies efficiently you should be safe unless you have an hard drive failure.

    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.

  2. 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.

  3. 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.

  4. My own experience is that XP 64 is one of the worst operating systems I've worked on in terms of performance.
    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.

  5. Yes, should work
    title Loading XP install - plain /I386/SETUPLDR.BIN
    chainloader /I386/SETUPLDR.BIN

    Just to be sure, you mean:

    title Loading XP install - plain /XP64/I386/SETUPLDR.BIN
    chainloader /XP64/I386/SETUPLDR.BIN

    in your layout, correct?

    And

    .\XP64\WIN51

    .\XP64\WIN51AP

    .\XP64\WIN51AP.SP2

    .\XP64\NTDETECT.COM

    .\XP64\TXTSETUP.SIF

    should all still stay there?

  6. General grub4dos informations: integrated help file

    http://grub4dos.sourceforge.net/wiki/index...ub4dos_tutorial

    http://diddy.boot-land.net/grub4dos/Grub4dos.htm

    Grub4dos can chainload setupldr.bin: no need for a boot sector file.

    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?

    title Windows XP PRO 64 SP2 - multi boot 
    map --mem /XP64/I386/SETUPLDR.BIN (rd)

    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?
  7. This “Boot Record” must reside at sector 11 (17 decimal) in the last session on the CD. The Boot Record contains an absolute pointer to the Boot Catalog.

    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.

  8. Once you turn ON your PC, when the DVD player starts to read the DVD, the very first bits it reads are those who tell the PC whether this is a bootable DVD or not. Once the PC "knows" that it's handling with a bootable DVD, asks you if you want to boot from it and if you "Press any key to boot from DVD" it starts of by reading the next bits. Those bits are CD Shell's binarys
    Yes, I knew all that, but what binaries are they, how does the booting PC know it should read those, where is this set?
  9. 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%

    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.

    Don't compare different setupldr.bin. They goes to different solutions.

    Again, you are mixing solutions, ask details at proper thread.

    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.
  10. 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?

  11. What's (SP2+) ?
    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..
    Is there an easy way to obtain such image from an official XP64 iso without having to use Isobuster?

    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?

  12. It's the same thing.

    It is the "Microsoft Corporation.img" or "Arnes Boot Record" which is the El-Torito no emulation boot image and that is written to the CD bootsector.

    it's called Boot Sector, it's the 2048 bytes long file that ends like this:

    pro1dat.gif

    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?
  13. set setupldr=SETUPLDR.BIN
    set char4=XP64

    gsar.exe -o "-s:x46:xda:x74:x03" "-r:x46:xda:xEB:x1A" %setupldr%

    gsar.exe -o "-s\i386\ntdetect.com" "-r\%char4%\ntdetect.com" %setupldr%
    gsar.exe -i -o "-sAMD64:x5C" "-r%char4%:x5C:x00" %setupldr%
    gsar.exe -o "-sAMD64:x00" "-r%char4%:x00:x00" %setupldr%

    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!

  14. In other words flyakite's original approach is "bring back to CD a HD install", whilst cdob's suggested one is "modify the original CD based install to work from a different path".
    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.

  15. As long as the fix concerns the installation process i really can't see how it could be different for x86 or x64.

    You forgot that the problem had nothing to do with the version of windose, nvidia changed their installer that's all.

    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?

  16. Windows supports one volume-name at CD. Do you need different volume names?
    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.
    This old release dosn't support XP SP2.

    BCDW 2.01a support XP SP2 x32. http://www.wolfgang-brinkmann.de/bcdw_e.html

    However no idea about XP x64, this may work or not.

    Thanks for that. I hope it does work with x64, I'll let you know how it works out.
    I also have the \$OEM$ in the root of the dual-boot-installer
    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..
    A XP x64 example, slightly different to flyakite's guide: http://www.msfn.org/board/index.php?s=&amp...st&p=814566

    You may use \XP_1\$OEM$ and \XP_2\$OEM$

    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..

×
×
  • Create New...