Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content Count

  • Donations

  • Joined

  • Last visited

Everything posted by Legorol

  1. Please include KB2964358 in the update list. This is a critical IE8 security update for XP SP3 that Microsoft released on 2014/5/1, despite saying they will not release any more security updates for XP. Security bulletin: https://technet.microsoft.com/en-us/library/security/ms14-021.aspx Update description: https://support.microsoft.com/kb/2965111 Download page: http://www.microsoft.com/en-us/download/details.aspx?id=42588 The update is available for other combinations of IE versions and Windows versions as well.
  2. Thank you. With regards to the Office Compatibility Pack, I also did a test. For sake of completeness, here is the result. I did a clean install of Windows XP SP3. I enabled Microsoft Update. I installed all High Priority Updates for XP and IE, but no optional software or other updates. This cleared the High Priority Updates list. I then installed the Office Compatibility Pack only (FileFormatConverters.exe) and no other software. I then visited Microsoft Update, and were offered these High Priority Updates: Security Update for Microsoft Office 2007 suites (KB2687499)Security Update for Microsoft Office 2007 suites (KB2760416)Update for Microsoft Office 2007 suites (KB2596848)Security Update for Microsoft Office 2007 suites (KB2687311)Security Update for Microsoft Office 2007 suites (KB2596672)Security Update for Microsoft Office 2007 suites (KB2596615)Security Update for Microsoft Office 2007 suites (KB2596785)Security Update for Microsoft Office PowerPoint 2007 (KB2596843)Microsoft Office Compatibility Pack Service Pack 3 (SP3)Note how the list includes KB2596848 but not KB2760591. Out of that list, I installed only the Office Compatibility Pack Service Pack 3, then revisited Microsoft Update. This time, I was offered this list: Security Update for Microsoft Office 2007 suites (KB2878236)Security Update for Microsoft Office 2007 suites (KB2817641)Security Update for Microsoft Office 2007 suites (KB2760591)Security Update for Microsoft Office 2007 suites (KB2827326)Security Update for Microsoft Office 2007 suites (KB2760411)Security Update for Microsoft Office 2007 suites (KB2597973)Update for Microsoft Office 2007 suites (KB2767849)Security Update for Microsoft Office 2007 suites (KB2687499) - note: superceded by KB2767849Security Update for Microsoft Office PowerPoint 2007 (KB2596843)On that list, KB2767849 actually supercedes KB2687499, so the latter can be ignored. All remaining items match correctly with your update list, except for the oartconv update (KB2760411). In conclusion: I verified that the Office Compatiblity Pack updates on your list are now complete and correct.
  3. You are right, there is something weird about the replacement informations. On the security bulletin page, it does say KB2760591 replaces KB2553090. On the other hand, on the component specific page (https://support.microsoft.com/kb/2760591), it says that this update does not replace any other update. This is what you can find on the three relevant update pages: Update File name File version File size Date TimeKB2760591 Oartconv.dll 12.0.6683.5002 8,581,824 13-Aug-2013 10:23KB2596848 Oartconv.dll 12.0.6665.5003 8,581,768 24-Sep-12 20:05KB2553090 Oartconv.dll 12.0.6565.5000 8,578,936 04-Aug-2011 02:17Edit: Note that KB2596848 is NOT a security update, so there is no associated security bulletin. This would explain why MS13-085 references only MS11-072, and it lists KB2760591 as replacing KB2553090. From the point of view of security updates, that is the correct replacement information.
  4. Great work, thank you. It will make it much easier for me to collect all Office 2003 updates now that support is over. However, I noticed that you may be missing an update. Under the Office Compatibility Pack category, you have oartconv2007-kb2596848-fullfile-x86-glb.exe. I beleive that this has been superceded by a more recent update. Here are the details of the newer update: Security bulletin: http://technet.microsoft.com/en-us/security/bulletin/ms13-085 Overview KB article: https://support.microsoft.com/kb/2885080 Component-specific KB article: https://support.microsoft.com/kb/2760591 The new update is oartconv2007-kb2760591-fullfile-x86-glb.exe, available from http://www.microsoft.com/en-us/download/details.aspx?id=40620. Note that you already have the latest update for Excel (xlconv2007-kb2827326-fullfile-x86-glb.exe) released as part of the above security bulletin.
  5. That reasoning is wrong in my opinion. Firstly, that way you are making your work unreliable and useless in a business environment. There are plenty of small- and medium sized businesses still running XP who would find it very useful to be able to easily get all the XP updates in one package. Secondly, there are hobbyists, enthusiasts, diehards and others, not necessarily in a business environment, who use XP with a lot of functionality, including Active Directory. Again, you are making your set of updates unreliable for them. The bottom line is: I don't think you should make a selective decision about which updates your users may or may not want. That choice is your users', not yours. You should create a complete set. As far as I'm concerned, knowing that you are arbitrarily choosing to exclude certain security updates, and that this is not even mentioned anywhere in an obvious place, just made your list of updates completely unreliable for me. How can I even find out which updates you chose to exclude, so that I can manually download those? Do you have a list somewhere? If I hadn't accidentally realised that KB2933528 is missing, I would have never known that some security updates are not included in your update list. I would like to politely urge you to reconsider your policy and include ALL security updates in your list, regardless of what functionality they target. Bear in mind that, as you publish your final XP list, it will become a lasting product that many people will rely on now and in the future.
  6. What's the reason for making security updates for Active Directory an exception? It seems to me that this makes the updates incomplete and hence the list unreliable for use in a production environment. If there is some deeply rooted explanation, I would love to know. Edit: KB2626416 is also a security update for Active Directory Application Mode, yet it's included in your list.
  7. The 2014 March 11 update of the list is missing the new update KB2933528 applicable to Windows XP SP3, released on the same date: https://support.microsoft.com/kb/2933528 This new update replaces KB2626416 (currently included in the list) and KB2801109 (currently not in the list).
  8. @wimb: Yes, it looks impossible to affect the contents of boot.ini during text-mode setup, so I have given up on it. Booting to Recovery Console once isn't a horrible solution. I don't think this would work. For starters, these are just the options that come at the end of a line in boot.ini, I don't see how this could affect the ARC path. Also, the options in txtsetup.inf are for setupldr.bin, and are a bit different from what ntldr accepts.
  9. I could get the $OEM$\$1 working and got it to copy files during text mode (although it wouldn't work without a winnt.sif with at least some entries). Unfortunately it has the same problem as any attempt before: Setup overwrites boot.ini right at the end, just before reboot.
  10. @nimb: That is very interesting, I will try your suggestion out with $OEM$. @nilkanth: It sounds to me like you are mixing two entirely different sets of procedures up. If you have a winnt.sif file, that means that you have used winnt.exe or winnt32.exe to start preparing the installation, but you are trying to follow my procedure for installing from USB, which is a different procedure. Some explanation: When you use winnt.exe or winnt32.exe, a set of temporary folders are created, which setup will look for later on. However, you didn't copy those to your USB drive (you only copied the i386 folder), and so you are running into problems. The instructions I posted in the first post are NOT using winnt.exe or winnt32.exe to start the installation. There is no winnt.sif involved with my procedure, nor any temporary folders. Also, you seem to have a misunderstanding about what "text mode setup" means. "Text mode setup" is all the steps that take place on the text screen with blue background and white letters. The text mode setup includes: computer boots, blue screen with white text is displayed, setup loads a set of drivers, setup examines your disks, you are prompted to accept the EULA, you are offered a choice of disk to install Windows on, and finally a yellow progress bar shows a large number of files getting copied over. The text mode setup ends when a 15-second countdown with a red progress bar appears saying that your computer will reboot. EDIT: couple of other points: Looks like you are trying to perform a fully unattended setup. My procedure was not developed for that. Are you by any chance trying to use a product key and/or CD for an *upgrade* version of Windows XP, and not a full retail or OEM version? My procedure requires that you place the modified copy of txtsetup.sif in the *root* directory of your USB drive (for example, D:\), not in the I386 folder. Otherwise it won't get read by setup.
  11. Based on jaclaz's ideas, I tried a few experiments out to get BOOT.INI to have the correct entry, without any success. I concluded that Setup inspects BOOT.INI when it starts (or at least no later than the start of the file copy part), adds an entry to it and then writes an entire BOOT.INI out after the file copy part. Therefore, the contents of BOOT.INI can't be affected by actions during the file copy part. That was the last remaining avenue I was going to investigate in this topic, so as far as I am concerned I'm finished with this "mission". :-)
  12. I see, but isn't EHCI the name in Windows XP? XP supports all three of the standarsd: OHCI, UHCI, EHCI. Of these, EHCI is the one that supports USB 2.0. See here: http://en.wikipedia.org/wiki/EHCI#EHCI If you don't install the EHCI service, doesn't that result in the USB drive/stick working very slowly? Edit: Or is there something special about the "REM 2000" tag? Do these lines execute on XP but not on 2000?
  13. Great work on this tool! It works very nicely. I was poking around in the files, and I have a question: in files\winsetup\setup.cmd, I noticed that all entries relating to EHCI are commented out with "REM 2000". This includes both the Services and CDDB registration. Why is this? Edit: version is 1.0-beta 7
  14. @jaclaz: I can hopefully get around to testing some of your ideas, they are interesting. @ilko_t: Thanks for the links! I have seen the first one already, I used it to my advantage. I realise that what I was doing is not new, and in fact all the issues in it have been fixed long ago :-) There are nice tools out there. I was trying to make sure I have a good understanding of what I read, and to have a go at doing things manually, as simply as possible. I agree that the drive letter D is a big limitation. It's not too bad if you can predict it beforehand, since Setup assigns drive letters in a documented way, but it can definitely get tricky. I liked the idea of using a drive letter because once you are done partitioning, that doesn't change, whereas ARC path does if you change what you boot from.
  15. That is an excellent point you bring up about Setup for dual-booting, didn't think of that. So I tested it, and the conclusion is this. If BOOT.INI is present when Setup starts, then Setup will only append to it, but if it is not present at the start, a new one is created, overwriting any that is copied during the Setup itself. Sadly. I have seen your binifix batch file included in USB_MultiBoot_10.zip at http://www.911cd.net/forums//index.php?showtopic=22857. As you say, it is doing the job of correcting the BOOT.INI entry at the end of the GUI Setup.
  16. Sadly this idea didn't work out, thwarted by Setup Steps: 1) I put a file "test.txt" in the \I386 directory of the USB stick. 2) In txtsetup.sif, in [systemPartitionFiles], I added a line: test.txt="\" 3) In [sourceDisksFiles], I added a line: test.txt = 1,,,,,,_x,1,0,0 I then did Setup as usual. Result: test.txt appeared both in C:\ and C:\WINDOWS, as expected. (Changing the 0,0 to 3,3 would eliminate copy in \WINDOWS). Instead of test.txt, I repeated the experiment with a boot.ini file with the correct multi(0)disk(0)rdisk(0)partition(1) line. Sure enough, it got copied to \WINDOWS, but the boot.ini in C:\ was still the one normally created by Setup It means that Setup creates boot.ini after file copy, and completely overwrites it. Another idea: try to copy the real NTLDR to the root of the USB stick during text-mode setup, to replace setupldr.bin. Together with a correctly prepared boot.ini, what this means is that when text-mode setup is complete, could just reboot from USB to resume setup. This would be a destructive change, but at least no Recovery Console need. So the aim: get Setup to copy a file to D:\. Steps are similar to before: 1) Put "test.txt" in \I386 of the USB stick. 2) In txtsetup.sif, in [systemPartitionFiles], add a line: test.txt="D:\" 3) In [sourceDisksFiles], add a line: test.txt = 1,,,,,,_x,1,0,0 To my surprise, test.txt showed up in C:\ instead of D:\ (as well as in C:\WINDOWS, but that's expected). I tried a few alternative paths: "\\.\D:\", "\\.\Physicaldrive0" and "\\.\Physicaldrive1". Each time, test.txt showed up in C:\ (Note: I reformat C: each time, so the file wasn't just accidentally left there). Back to the drawing board!
  17. Fun it is! I was just reading up on this area. Thanks for the links! It is hard Remember, Microsoft didn't intend for us to install XP from USB Batches are technically allowed though, since you can create them in Notepad B) however the aim is simplicity, so a 300 line batch that you have to type in yourself wouldn't work. Sadly yes, so for now "running 7 and install XP" or at least "make bootable stick in 7 and do the rest in XP". Idea: Get an inf-based method to copy boot.ini over from the USB stick to the Harddisk during text-mode Setup. Maybe migrate.inf, maybe txtsetup.sif, it's too early to tell. I wonder what happens, whether Setup would just overwite it at the end of text-mode before the reboot. I will see.
  18. This is very nice. I don't think I have seen this use of SetupSourceDevice anywhere, which is why I posted it. I came up with the idea after reading Naming Files, Paths, and Namespaces. I was reading today about techniques for assigning a fixed drive letter to the USB stick, for example as mentioned in . It just occured to me that once you have a fixed drive letter, you can use \GLOBAL??\D: in a predictable way. Yes, you are right. If you don't already have a bootable USB stick, you are stuck under XP. However, when you buy them in the shop, nowadays USB sticks come prepartitioned already, so you are not too far away, and just need to format it. That you can do under XP as well, so the only snag under XP is the "drive number". As for what this snag is, as we discovered over at http://www.911cd.net/forums//index.php?showtopic=24395, the VBR code uses the driver number in the BPB to try and load NTLDR. If it's not the correct number, you get a "Disk Error" when trying to boot. I see, this could work. Unfortunately I won't be trying this due to time constraints. It digresses a bit too much from my original goal, and I would like to do some other experimenting. Maybe later Actually, I was kind of hoping to distill a procedure that is as simple as possible and relies on no other tools so that maybe it can be written up as a general guide. I can now install from the USB stick almost like from a CD, with only the following extra steps required: * Make your USB stick bootable (this could be a bit technical, but is easy under Win 7 by just partitioning/formatting) * Copy 3 extra files (setupldr.bin, ntdetect.com, txtsetup.sif) * Edit 2 lines in txtsetup.sif in Notepad * Create a boot.hdd file with 2 lines in Notepad * Enter Recovery Console once to copy 1 file Still a bit on the technical side, but not too bad If I can find a (simple) way to avoid having to enter Recovery Console, I would be happy.
  19. I forgot to mention that I also tried the procedure I describe in the first post by setting SetupSourceDevice="\GLOBAL??\D:", instead of "\Device\Harddisk0\Partition1". This has an advantage. As you know, the Device paths get assigned depending on what device you boot from: if you boot from USB, then the USB is Harddisk0 and the internal Harddisk is Harddisk1, but if you boot from the internal Harddisk, that is Harddisk0. However, drive letters are always assigned starting with the first partitions of internal Harddisks. So if you just have one internal Harddisk with one partition, and one USB stick, then the internal partition is always C:, and the USB one is D:, no matter how you boot. What this means is that drive letters remain consistent throughout setup. If you use SetupSourceDevice="\Device\Harddisk0\Partition1" and follow the procedure in the first post, then during the GUI portion of setup, it asks for the location of files a number of times (about 20 in total). This is because for the GUI portion, I was booting from the internal Harddisk, so that is Harddisk0. However, if you use "\GLOBAL??\D:", setup finds the files on the USB stick both during text and GUI portion. The only thing to watch out for is at the start of the text portion of setup, when you are repartitioning your internal Harddisk. After you are done with that, reboot once and restart setup to make sure the drive letters are assigned correctly.
  20. It's a shame that debug doesn't work for sector writing. The issue under XP is this. As I'm sure you know, a USB stick is seen as removable media by XP, even if it's partitioned like a Harddisk (with MBR etc.). XP can format the drive, which just reformats the existing partition without touching the MBR or partition table. When you do so, XP writes the drive number 00h in the BPB of the formatted partition. This often causes problems when trying to boot the stick, because when booting, the stick is (or should be) emulated as a Harddisk and is accessible by drive number 80h. I finally understood what your idea was by using a fake installation. So I set one up on the USB stick in a WINDOWS directory, as you describe in http://www.911cd.net/forums//index.php?showtopic=20983&st=25. I proceeded with text-mode setup first, and then booted to Recovery Console. Sure enough it offered me a choice of logging into C:\WINDOWS and D:\WINDOWS, where C was the Harddisk and D the USB stick. I tried both, and tried to use bootcfg. Unfortunately however, bootcfg only offered to add C:\WINDOWS to boot.ini, it didn't see the D:\WINDOWS directory. So this didn't help. I take your point about not renaming system files, the caution is justified. I think just for the purpose of this project, I was OK. I was envisioning a scenario where you might be stuck with a restricted set of tools, for example because you are out visiting a client site.
  21. That is true, but there are a few reasons why I didn't use it. An NT 6.x type bootsector seems to boot setupldr.bin just fine, when renamed correctly. It's also debatable whether my mission restriction (use standard Windows 7) allows the use of bootsect.exe or not, since bootsect.exe is only found on the Windows 7 DVD and isn't installed on the computer by default. What if you don't have the Windows 7 DVD with you? ;-) I also wanted to keep it as short and simple as possible (which is a contradiction, considering I'm trying to install from USB ;-) ), so if it's not necessary, I didn't include it. There is another consideration as well though. The procedure as I described actually almost works using Windows XP instead of Windows 7. The only snag under XP is that it's not as straightforward to make your USB stick bootable. You would need a third party tool in that case, if only to change the drive letter to 80h in the BPB and optionally change the FAT type to LBA. However, running something like the HP USB Tool to format with instead of Windows Explorer is sufficient. Everything else works as is under XP too, so I didn't want to include the use of bootsect.exe. I tried bootcfg, but there doesn't seem to be a way to actually edit the ARC path. When you add a Windows installation with bootcfg, it constructs an incorrect ARC path just like setup does. Please let me know if I missed an option to bootcfg or something, this would be a good improvement to my procedure :-) This is very neat, I will remember this! Luckily this wasn't necessary for me, I was able to access both C:\ and the USB stick and copy a file over. I can see how this trick can be useful though.
  22. This is a report of the culmination of my successful adventure. I have been researching the topic of installing XP from USB, and after learning a lot from this and other forums, I set myself a challenge. Based on all the available knowledge, is it possible to install XP from USB using no third party tools, except what's available to me in a standard Windows 7 installation? I realise that there are now lots of good tools available online for a variety of installation scenarios, but there is something satisfying about managing to do this "out of the box". The scenario. Available to me were: * Legitimate Windows XP with SP1 setup CD. * Target computer: has 1 blank Harddisk and can boot from USB. Aim to install XP here. No CD drive. * "Work" computer: standard Windows 7 installation, used for preparation. * Blank 1 Gb USB stick. The restriction was that I could only use whatever tools are included in Windows 7 on the Work machine. No third party applications. In addition, I aimed to make the fewest possible tweaks along the way. The steps that worked successfully to install XP from USB, exactly as written, from the first to last step. Some additional remarks are at the end. Steps 1 - 5 are performed on the Work computer. Steps 6 - 10 are performed on the Target computer. Step 1) Partition and format the USB stick in Windows 7, which makes it bootable: Start Command Prompt, start diskpart. Enter commands: select disk 2, clean, create partition primary, active Exit diskpart, unplug and replug the stick. Format the stick via Windows Explorer (I chose FAT32). Note: the value in "select disk 2" depends on the number of harddisks and other USB storage devices you have! You have to check what value is appropriate for your system (use "list disk"). I have two Harddisks and disconnected all other USB storage devices, hence the value is 2 for me (numbered from 0). Step 2) Copy contents of Windows XP with SP1 setup CD in whole to the USB stick. Step 3) Copy these files from \I386 folder to \ on USB stick: setupldr.bin -> bootmgr (rename), ntdetect.com, txtsetup.sif Step 4) Edit \txtsetup.sif to add two lines in [setupData] section: BootPath = "\I386\" SetupSourceDevice = "\Device\Harddisk0\Partition1" Step 5) Use Notepad to create a file named boot.hdd at \ on USB stick with these two lines: [Operating Systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP" /fastdetect Step 6) Boot from the USB stick on the Target computer. This starts the text-mode portion of Setup. Follow the instructions on-screen, creating/formatting a partition on the Harddisk as needed in the process. Make sure to install Windows XP in the first partition, in the WINDOWS directory. Step 7) When Setup reboots, reboot from the USB stick again and enter Recovery Console. If you try to boot from the Harddisk at this point, you'll get a hal.dll error. Step 8) Using the Recovery Console, rename c:\boot.ini to boot.bak. Copy \boot.hdd from USB stick to c:\boot.ini Step 9) Reboot, this time from the Harddisk. This starts the first GUI portion of Setup. Proceed as normal, but you are asked for the location of various files several times along the way. Each time answer with D:\I386, where D is the drive letter of the USB stick at this point. Trial and error works here. Have to do this about 20 times total. Step 10) When setup reboots again, reboot from the Harddisk. This is the last GUI portion of Setup. Proceed as normal. Done! This process took me 61 minutes from start to finish, which included 30 minutes for copying the contents of the CD onto the USB stick. The process is non-destructive in the sense that it does not modify the contents of the USB stick in any way. Remarks * Using Windows 7, partitioning with diskpart and formatting via Windows Explorer is actually sufficient to create a bootable USB stick. The resulting stick will boot in most modern PCs, and a lot of older ones. When formatting, Windows 7 correctly enters drive number 80h in the BPB of the partition on a USB stick (unlike Windows XP, which enters 00h, leading to issues with bootability). However, creating a bootable USB stick is not always an easy or guaranteed process. It worked for me on my hardware, but your milage may vary. * Conventionally, setupldr.bin is renamed to ntldr, but I had to use bootmgr instead, because naturally the VBR code placed by Win 7 loads that one. * As is well-known, XP setup can be performed from a properly prepared local source on the USB stick, using $WIN_NT$.~BT/$WIN_NT$.~LS. What's less known is that setup can be booted and performed from *any* directory, using BootPath and SetupSourceDevice. These two settings are honoured if placed in txtsetup.sif in the current directory next to ntdetect.com. SetupSourceDevice overrides the need for a CD drive. * The value of SetupSourceDevice can be any valid NT device path. When booting from a USB stick, the stick normally gets assigned as \Device\Harddisk0. The fun thing is that other paths also work, for example "\GLOBAL??\D:", where D is the drive letter assigned to your USB stick when booting from it. (Bit of trial and error needed here). The trick is that all Win32 device paths are actually a subset of all NT device paths, attached under \GLOBAL??. Note that paths other than NT device paths don't work (such as ARC paths, or direct Win32 paths such as "D:" or "\\.\Physicaldisk0". * There is no need to prepare winnt.sif * The deal with having to prepare a boot.ini file in advance and copy it over using Recovery Console is because of the ARC path problem arising from booting from USB, which leads to the (in)famous hal.dll error. Sadly Recovery Console doesn't allow file editing, so the correct boot.ini has to be prepared in advance. This issue is well-documented, so just in brief: When booting from USB under XP (and its setup), the USB stick is assigned multi(0)disk(0)rdisk(0), and the internal harddisks are assigned multi(0)disk(0)rdisk(1) onwards. When booting from the harddisk, it is of course assigned multi(0)disk(0)rdisk(0). Since the setup was started by booting from USB, an incorrect boot.ini file is created on the harddisk (with a multi(0)disk(0)rdisk(1) entry). In order to correct this and allow booting from the harddisk, the boot.ini file on the harddisk needs fixing.
  • Create New...