Jump to content

Troubles with integrated install from DOS


Recommended Posts

Pardon if this is a newbie question [new to preinstallation stuff, not to most other things!]

Starting from an image of OEM XP SP2 [VRMPOEM_EN] and pointing each post-sp2 hotfix at it such as

WindowsXP-KB834707-ENU.EXE /integrate:E:\XPCD

My problem of the moment [ignoring for the moment the problems of interaction of hotfixes, etc.] is that

when I attempt to boot to DOS

A>smartdrv

E:

cd \XPCD\I386

I am getting error messages for three files SPCUSTOM.DLL, UPDATE.EXE, and UPDSPAPI.DLL. The install only allows me to retry or give up or ignore them.

I looked in the I386 directory and found a subdirectory E:\XPCD\I386\UPDATE which has the three files. So, I copied them into the I386 directory one level up, but this doesn't help.

Am I doing something wrong, leaving out some other step? [i do notice that a DOSNET.INF file is created, along with a proper appearing SVCPACK.INF file as well as the SVCPACK directory with all of the shortened-name hotfixes [Q834707, etc.] and their respective .CAT files, etc.

The errors seem to be harmless, and there are no further consequences I can see. All of the updates I added DID seem to be installed, as Windows Update says they are there [meaning it only wants me to install the ones it has that are NOT in my updates, etc.] and additionally, I can confirm them with QFECHECK from Q282784 and even using an UPDATE.EXE /L.

I haven't tried a burned version [a separate post on that!], but is this method only meant for booting the CD, or is the DOS method ok?

Thanks in advance for any help here.

cjl [contributor to the 98se unofficial service pack]

Link to comment
Share on other sites


Did you add the hotfixes in order? If you integrate hotfixes out of chronological order, you run the risk of having mismatched files. This is probably what you are experiencing - I've found it easier to install a virgin XP SP2 machine in a VM, go to Windows Update and check the box. Download the full version of each and every update listed under both the critical and suggested sections, and note the release date (do not do it by the article number, as these are NOT chronological). Integrate patches from oldest release date -> newest release date, and you should be fine. I've had problems before, and I've found that integrating in the proper order really does matter.

Slightly OT but still of value, here's a script that I made to get the oddball suggested applications that can't be integrated installed - it's called from [setupParams] section of WINNT.SIF (T-9min):

---unattend.cmd---

:// Install Journal Viewer.

msiexec /i %sourcepath%\unattend\jrnlvwr\jrnlvwr.msi /q

:// Install HighMAT CD writing update.

%sourcepath%\unattend\hotfix\HMTCDWizard_enu.exe /qn

:// Install .NET Framework 1.1 with SP1 and SP1 hotfix.

%sourcepath%unattend\dotnetfx\dotnetfx.exe /q:a /c:"install /l /q"

%sourcepath%unattend\dotnetfx\867460.exe /q

%sourcepath%unattend\dotnetfx\886903.exe /q

:// Install Media Player 10 and Windows Media Connect.

start /wait %sourcepath%unattend\wmp\MP10Setup.exe /q:A /c:"setup_wm.exe /Q /R:N /DisallowSystemRestore"

%sourcepath%unattend\wmp\wmcsetup.exe /q

:// Install BootVis (the .mst was created by me).

msiexec.exe /i "%sourcepath%\unattend\bootvis\bootvis.msi" TRANSFORMS="%sourcepath%\unattend\bootvis\bootvis.mst" /qb!

:// Install Windows Messaging Components (Messenger 5.1, Office Communicator 2005).

msiexec.exe /i "%sourcepath%\unattend\winmess\messenger.msi" /qb!

msiexec.exe /i "%sourcepath%\unattend\winmess\communicator.msi" /qb!

:// Install XP PowerToys.

"%sourcepath%\unattend\xppower\deskman.exe" /v/qn

"%sourcepath%\unattend\xppower\taskstch.exe" /v/qn

:// Install recovery console.

%sourcepath%i386\winnt32 /cmdcons /unattend /dudisable

:// Change boot.ini timeout to 3.

bootcfg /timeout 3

:// EOF

---unattend.cmd---

Have fun, and good luck.

Edited by cluberti
Link to comment
Share on other sites

Thanks cluberti for your neat suggestions. I certainly will want to use stuff like that, but remember, at this stage I'm not using any winnt.sif input at all, just applying the /integrate form of hotfixes, nothing else, over a virgin image of XP pro SP2 [VRMPOEM]. This is why I asked if I need to do anything else, i.e., doing just the hotfixes themselves is perhaps inadequate to a viable result?

I did not use anything but the numerical order slightly modified to achieve less conflicts, so clearly this is wrong and likely part of the problem, so I need to re-order the hotfixes, etc. A question: Can I use the digital signature date inside of the fix itself [properties shows it] as the basis of the sort?

Also, I see mention of a hotfix tool apparently to force things regarding interaction with I believe 885835 and at least one other fix it doesn't "like". Can I assume the purpose of the tool is to get the entries in SVCPACK.INF to happen when the /integrate switch doesn't work and play well with the others? But if it gets into SVCPACK.INF it *will* work? If so, then this tool is a good way to avoid manual additions to SVCPACK the directory and svcpack the .inf file and nothing else? [is that correct?]

I am doing all of this on a T30 using the SLP key to create a test system installed on a higher clean volume letter. [C: pre-installed IBM system, D: my files, E: XP images drive, test install on F:; all this on a 40 GB disk! All partitions are FAT32 and boot to a USB external floppy with the DVD/CD drive in all the time and the BIOS set for the USB BIOS BOOT support, etc. to get started from a 98SE startup disk with SMARTDRV installed there, etc. [i appreciate the use of a VM and a mounted .ISO image, but I fear the overhead of VM on this already taxed machine; is there any reason why my way is inherently "wrong" for testing?]

I'm trying to learn this stuff a step at a time until I understand it and it functions to the point of inherent limitations of what I am doing; then I prefer to go on to the next step, etc. so I don't get confused!

So, is the creation of this I386\UPDATE directory "normal" and merely an ignorable artifact, or is its mere presence indicating I screwed up? [As I said, it seems to ignore the files even though I am quite early into the install in the text screens, before anything would involve actually installing the hotfixes themselves, which in turn seems to itself be ok, etc.] It cannot be a concidence that the very files that get these early error messages are all three the only contents stored there, etc.

I also know that eventually, I need to "brand" the image, so that I don't have to put up with the activation messages, but this is just a transient test install; it won't even be there 30 days later! [i DO know that I could move in the OEMBIOS files on my C: drive to various places to shut down that, but this is clearly a topic for much later in the game than where I am now!] My ultimate purpose is to get an image I can do a repair install for my C: drive and in the eventual future a clean install there as well, etc.

I really appreciate all the help on this forum; as I said, I am a newbie to this quite esoteric subject, but generally a veteran of many other related things, manually installed, etc.

cjl

Link to comment
Share on other sites

"I certainly will want to use stuff like that, but remember, at this stage I'm not using any winnt.sif input at all, just applying the /integrate form of hotfixes, nothing else, over a virgin image of XP pro SP2 [VRMPOEM]. This is why I asked if I need to do anything else, i.e., doing just the hotfixes themselves is perhaps inadequate to a viable result?"

It depends on what a viable result is, I gues. The stuff listed below (minus bootvis, powertoys, and the recovery console) are all listed on Windows Update, but cannot be easily integrated into the install source, and that's why I put them there.

"I did not use anything but the numerical order slightly modified to achieve less conflicts, so clearly this is wrong and likely part of the problem, so I need to re-order the hotfixes, etc. A question: Can I use the digital signature date inside of the fix itself [properties shows it] as the basis of the sort?"

More than likely this is the root cause of your problem, and yes, using the release date in the digital signature should be good enough. The date is also on the download page for each hotfix on the MS site as well, and I went by those without any problems.

"Also, I see mention of a hotfix tool apparently to force things regarding interaction with I believe 885835 and at least one other fix it doesn't "like". Can I assume the purpose of the tool is to get the entries in SVCPACK.INF to happen when the /integrate switch doesn't work and play well with the others? But if it gets into SVCPACK.INF it *will* work? If so, then this tool is a good way to avoid manual additions to SVCPACK the directory and svcpack the .inf file and nothing else? [is that correct?]"

It's worth a try :), but just make sure you are integrating (or forcing) hotfixes into the install source in the proper order. I've never tried it (I just let WSUS install the updates post-install), but I've heard it works properly. There are at least two hotfixes known to have trouble integrating into the XP source.

"...is there any reason why my way is inherently "wrong" for testing?"

Not necessarily, but without actually testing it through a "real" install, there's no way to be 100% sure it works. Assuming you have a decent procesor in there, you should be easily able to run a VM. You would only likely need to be running one machine at any one time, and if you can spare 256MB of memory to devote to the VM whilst it is running, this is more than enough for VM testing.

"So, is the creation of this I386\UPDATE directory "normal" and merely an ignorable artifact, or is its mere presence indicating I screwed up? [As I said, it seems to ignore the files even though I am quite early into the install in the text screens, before anything would involve actually installing the hotfixes themselves, which in turn seems to itself be ok, etc.] It cannot be a concidence that the very files that get these early error messages are all three the only contents stored there, etc."

Yes, the update directory SHOULD be there. And those are the three files that should be there as well, so your integration was most likely simply done out of order, and paying attention to the dates on the download site for each update (or the internal signature date) will help when you re-integrate the hotfixes on another clean SP2 source.

Just let me know if you need more assistance, and I'll try to help.

Link to comment
Share on other sites

"It depends on what a viable result is, I gues. The stuff listed below (minus bootvis, powertoys, and the recovery console) are all listed on Windows Update, but cannot be easily integrated into the install source, and that's why I put them there."

I appreciate the add-ons, later for me to digest and understand, etc. Viability in this case means that all that I do gets me working stuff with no problems. That more stuff that wants to be added later to avoid the likely need to install manually isn't the point [yet]!

This is why I want to know that what i am CURRENTLY doing isn't "wrong" just incomplete and in severe need of refinement, etc.

"More than likely this is the root cause of your problem, and yes, using the release date in the digital signature should be good enough. The date is also on the download page for each hotfix on the MS site as well, and I went by those without any problems."

I would think that the digital signature date is more accurate, because sometimes there are slight delays in the "official" release date as manually documented after-the-fact. As I understand it, the digital signature is added BEFORE the product is released to the distribution arm of MS, etc.

In any case, I have now re-ordered the hotfixes in the chronological order as indicated by the signature date. Curiously, two of the updates are EXACTLY the same to the second regarding the release date. In that singular case, I went in numerical order of the two.

The hotfix installation went smoother, and I only got two integration complaints for 867182 [i have 834707 and I understand these two hate each other] and 885250 [which apparently hates 886835?].

So, my expectation is to have all of the WU-provided updates per se, except for things like Media Player 10 and Media Connect, Mal software removal tool, and Highmat, and of course the two that wouldn't go in as described above.

If I can get all of this to work as it stands now, I will be quite happy until I go back and study more, etc.

""Also, I see mention of a hotfix tool apparently to force things regarding interaction with I believe 885835 and at least one other fix it doesn't "like". Can I assume the purpose of the tool is to get the entries in SVCPACK.INF to happen when the /integrate switch doesn't work and play well with the others? But if it gets into SVCPACK.INF it *will* work? If so, then this tool is a good way to avoid manual additions to SVCPACK the directory and svcpack the .inf file and nothing else? [is that correct?]"

It's worth a try :), but just make sure you are integrating (or forcing) hotfixes into the install source in the proper order. I've never tried it (I just let WSUS install the updates post-install), but I've heard it works properly. There are at least two hotfixes known to have trouble integrating into the XP source."

This isn't a problem. My .BAT file now looks like this:

rem Digital Signature Date taken from properties/Signature/Details

WindowsXP-KBxxxx-ENU.EXE /integrate:E:\XPCD

So, each hotfix has a date reference. All I have to do is substitute the hotfix tool for the two failing integration attempts. But I want to postpone this until it OTHERWISE works [see below].

"...is there any reason why my way is inherently "wrong" for testing?"

Not necessarily, but without actually testing it through a "real" install, there's no way to be 100% sure it works. Assuming you have a decent procesor in there, you should be easily able to run a VM. You would only likely need to be running one machine at any one time, and if you can spare 256MB of memory to devote to the VM whilst it is running, this is more than enough for VM testing.

I believe what I am doing is a *real* install, as I have in the past done precisely the same thing except added the updates in manually and/or Windows Update [for the short list of the updates WU provides compared to the hundreds actually available!]. The end result seems to be the same, as all seems to work as well as one would expect for a "short" install, no add-ons, etc. Windows Update says I only need the ones not there. QFECHECK and UPDATE/L both reveal that what's there is the same as a manual effort to get to the same place. Please give me anything you might suggest that might reveal this to be a *flawed* install? The only thing "shared" by the install with the main [C:] system is the entry in boot.ini for NTLDR to load this copy instead of the main copy, etc. since it installed on F: entirely and on an empty F: drive before the install. Also, I am recreating XPCD as a virgin copy from VRMPOEM_EN each and every time, so this is not a "contaminated" installation in that regard, etc.

If necessary, I am prepared to burn CD's because someone is giving me a spare 12 GB 2.5" Travelstar disk I can pop in instead of my disk. [One screw and you can pop out the hard disk in ThinkPad's !] Once I get to that stage, I can report on whether the booted CD version does/doesn't have the problem with regard to the update files, etc.

""So, is the creation of this I386\UPDATE directory "normal" and merely an ignorable artifact, or is its mere presence indicating I screwed up? [As I said, it seems to ignore the files even though I am quite early into the install in the text screens, before anything would involve actually installing the hotfixes themselves, which in turn seems to itself be ok, etc.] It cannot be a concidence that the very files that get these early error messages are all three the only contents stored there, etc."

Yes, the update directory SHOULD be there. And those are the three files that should be there as well, so your integration was most likely simply done out of order, and paying attention to the dates on the download site for each update (or the internal signature date) will help when you re-integrate the hotfixes on another clean SP2 source."

This time, the only change was less conflict, now only the two complaints which is apparently the norm for what I did.

So, unfortunately, there is no change from the previous install. I install from DOS with E:\XPCD\I386\winnt.exe after smartdrv. Barely into the install, it complains about the three files in three sets of error messages each letting me skip the file, but since there is no browse, just an abort, ignore and continue, or a useless retry, I don't understand why it cannot find the files. Remember, I also made a copy of the three files in the E:\XPCD\I386 directoty as well.

Apparently I am doing something else wrong.

The question remains: Adding hotfixes - Does this invalidate the DOS method of starting an install in any sense? Must it be either the long-form of the 6 diskettes bootup to the CD or a direct boot to a burned copy of my work is the only way to avoid these error messages [which apparently do have no consequences to the resultant install AFAIK].

Or another alternative:

Remember, I am NOT doing ANYTHING ELSE! Is perhaps this an improper approach? Must I use WINNT.SIF for this for example? There is a parameter somewhere for telling the install that the diskettes bootup is in the picture [meaning MS-DOS has something to do with it]. Perhaps it is NECESSARY to invoke this parameter to avoid this current problem?

Just let me know if you need more assistance, and I'll try to help.

Reading above, any assistance possible would be appreciated, help!

cjl [really appreciate this!]

Link to comment
Share on other sites

Hm - if you're getting errors after doing everything in order, I'm not entirely sure what's going on. There are a few hotfixes that don't necesarily integrate properly, but that's normal. If you still have an RTM Windows XP source, I may suggest that you restart - slipstream SP2, then integrate all of the hotfixes again to that source and see what happens. You may also want to do the install using the CD rather than from DOS (see the "Bootable Windows XP installation CD-Rom (with SP1) [updated! dec 17, 2002]" section from http://www.nu2.nu/bootcd/ for making your CD bootable), because I know for sure you shouldn't attempt the install with any type of hard disk TSR software, especially smartdrv.

If you need help with this, let me know.

Link to comment
Share on other sites

I have made some progress. I guess the DOS +smartdrv method cannot suprress the complaint messages, although the errors are *really* early on in the install proces, i.e., in the part that DOS copies the files to the hard disk, which is unique to the DOS-type install. Again, the weird thing is that how come DOS knows that the three files in question are even needed. [The question is: Where is it recorded that these files need to be added to presumably the mini-kernel image first placed on Drive C: for use in the install later; this is the stage *before* the mini-kernel runs to ask what drive to install/repair to, etc.] The strange part again, is why does it not find my copies in the I386 directory itself?

Regardless, I have found an easier way that takes full advantage of the situation:

Remember, this is a C: drive bootable XP system. So, I just invoked E:\XPCD\I386\WINNT32.EXE and was quite careful to tell it I needed to not upgrade and also I had to chose the drive info, etc. Via this method, all seems fine, no complaints, etc.

Additionally, I have used the hotfix beta 1.0 R 2 to integrate the two problem fixes 885250 and 867182. Since I am not sure if this tool is a *total* replacement for the /integrate method, I merely changed those two cases, and the rest are the usual /integrate method, etc. [What I mean is, that the *first* integration is responsible for making fundamental changes to the image files, while subsequent files just add additions into the then-existing files and directory [svcpack.inf, svcpack, etc. Perhaps this is assumed away by the tool? Even if so, it does get the job done!]

So, when I get to Windows Update, all I am asked to install are the updates I haven't fiddled with yet, so apparently all is well, as long as I do it this way, *or* actually burn a disk.

I do know how to burn a disk, I just want to get some more exact info about what I am telling Nero about the nuances of the file structure, since it can be demonstrated that the released RTM original XP disk slipstreamed to SP2 is *not* the same as MS's SP2-level disk and the closest you can get is to at least get the file structure to match. [i have seen a lot of free advice on the net about this, since there are contradictory instructions, it would appear that many people are getting it wrong, etc.]

Additionally, I located an excellent free-ware Windows "touch" routine so I can use "authentic" folder datesl since there does seem to be a convention for time-marking pretty much the entire structure, etc. [Windows has a bad habit of maintaining *file* dates but not *folder* dates which are made as of today, etc.]

I don't believe that it actually matters in terms of the install of the system, since generally file/folder names are merely case-retentive, not case-sensitive, but it *does* matter if the names get truncated instead of 123456~1.ext if that's what may be required in some context.

So, please follow my other thread on that nuance.

Thanks for the help in getting me at least this far; not having to deal with hotfixes is much of the work here!

cjl

Link to comment
Share on other sites

Also, I was able to recreate your issue by trying the exact steps you had taken with my own XP source. This source works just fine when doing an install directly from the CD, but when I boot to DOS and manually invoke setup, I get the complaints about those exact three files - seems like you've already gotten around this, but I thought I'd let you know as well. With or without smartdrv, installing using winnt.exe from a dos prompt gives these errors, every time. Making the CD bootable and doing a normal CD installation with the same files, no problem.

Link to comment
Share on other sites

Thanks for your confirmation of my [partial] sanity, cluberti.

However, I think the three complaints are ignorable, or at least so far they seem to be. Remember, I am not doing anything else at this point other than integrating lotsa hotfixes into the growing image. Perhaps this cannot be trusted once futher features are added?

To save space, is the following EXACTLY the way to get it to work:

In the image, make the ONLY file in the \I386\SVCPACK directory be MYSELFEXTRACT.EXE which in turn has in it all the files the integration added there before I zipped them? Additionally, add in a line to invoke MYSELFEXTRACT.EXE as the first thing done inside of SVCPACK.INF?

Is that correct? Or must some of the files be already there other than my zip.exe? This method will copy the files correctly into the temp area of the install?

Alternatively, [and if necessary if the whole thing CANNOT FIT on a CD], can I point to a static directory I separately place on the hard disk as a prerequisite to the install?

Final alternative, can I assume I can make a bootable DVD version? [if it doesn't fit on a DVD, I give up!]

[Does MICROSOFT CORPORATION.IMG work for DVD's?]

cjl

Link to comment
Share on other sites

Also note that there is something else that is not immediately apparent, but also 100% reproducible, using the DOS install method - the MSI engine is corrupt, and needs to be unregistered and re-registered before any .msi packages can be installed. Just an FYI, this happens EVERY time I do the DOS installation method.

I'd say the best way to do it would be to not install from DOS at all - make sure you're using a bootable install CD. Assuming you aren't installing a ton of applications from your CD, size really shouldn't be an issue. However, if you've got lots of drivers or custom apps taking up space, consider switching to DVD - or use a WinPE disk to begin your installation (via winnt32.exe). That way, you could copy the files to the HDD first, and then run setup from within the WinPE environment (bypassing the DOS limitations).

I'd say WinPE as a last resort though - most newer machines have at least a DVD drive, so trying to cram everything onto 1 CD isn't as necessary as it used to be.

Link to comment
Share on other sites

Thanks regarding the .msi engine problem from DOS; will be meaningful later when I get more things automated, etc.

For my testing, the use of WINNT32.EXE run from the pre-existing system installed on C: for the purpose of installing the test image which is on E: onto F: is fine for the moment. Obviously eventually I really don't want to have to install a system just to install the *real* system!

Yet, that DOES avoid the problem of a too-big image, which I am already starting to run into, since I am integrating about 55-60 hotfixes. The image size is about 705 MB.

Can't I just change the entry in SVCPACK.INF to point to another hard disk area where all of the files normal in \I386\SVCPACK are relocated to? Or are there other things "sacred" about where it defaults to?

I asked if MICROSOFT CORPORATION.IMG, the stuff that makes it boot a CD, is that good for a bootable DVD as well? [Never burned a bootable DVD; anything unusual to know other than the obvious [using Nero]?

Thanks for all the help,

cjl

Link to comment
Share on other sites

I currently use the method and files found on

http://www.nu2.nu/bootcd/

under the heading "Bootable Windows XP installation CD-Rom". Works great every time, and will burn the CD too if you've got a burner and an ASPI layer installed.

Oh, and if you are willing to modify a few system files you can change the location of svcpack, but I wouldn't. Technically, the files are working just fine - as long as you don't use DOS to install them :). That's why I suggested using the WinPE environment to install Windows if you don't want to use a bootable CD or DVD - you get a minimal Windows environment booted from the CD, from which you can run winnt32.exe - no secondary system needed, the install is done entirely from the system being installed to.

I'd still recommend doing it the old-fashioned way from a bootable CD or DVD, as it does work best and is the easiest to perform.

Link to comment
Share on other sites

I looked at the bootcd site mentioned, and although it does likely work, there are some picky points:

1) This package seems to want to invoke the Joliet file system, which is arguably incorrect. When you do the following, it will NOT product the same results:

Slipstream an image of XP to SP2 using /integrate of the SP2 .exe file itself. The resultant file has names that DO need Joliet to make them stay the same.

Problem is that the ACTUAL SP2 disk DOES NOT use Joliet, nor do the names exactly match! When there are problems, the slip-stream process makes names that not only do not conform to MS-DOS 8.3 conventions coupled with ISO 9660 restrictions [as does the ORIGINAL XP CD!], but are in fact containing lower-case characters.

The ACTUAL released SP2 XP CD uses the SAME names but ALL UPPER CASE. They aren't conforming to MS-DOS 8.3 conventions, but since they ARE UPPER CASE, they CAN conform to some aspect of ISO9660 because the names are NOT longer than 16 characters. For a practical example, deep within the \I386\ASMS\52 folder there is a directory that is called either:

NETWORKING [XP SP2 released CD]

NETWORKI [DOS view of above]

networking [XP slipstreamed to SP2; will read back as this if Joliet file system is used on the CD]

NETWOR~1 [DOS view of previous Joliet-requiring version]

Fortunately, all of this is a matter of "authenticity" because only a running system with full CD support in Windows ever accesses these odd directories, presumably during an install, etc. But that said, the only "right" way to do this is to NOT add Joliet support, but allow ISO-9660 to correctly form the upper-case "long" names, etc.

When using Nero, I suspect that this can be handled by NOT using Joliet, but rather by specifying some aspect of ISO9660 perhaps some "extensions" as Nero puts it [that they warn tend to make the disk LESS compatible but you CAN set them, etc.] or perhaps by INSTEAD setting the file system to "ISO-9660;1996" I believe it's called that perhaps understands just what to do.

In any case, looking at an actual MS CD with ISOBUSTER, you do NOT see a Joliet layer, as would be suggested by the Bart people in the link, etc.

Moreover, ISOBUSTER can lift for you MICROSOFT CORPORATION.IMG as is used in Win2K and all XP CD's if not elsewhere. This process has been discussed in many places, such as slip-streaming articles from The Elder Geek or even Paul Thurrott, etc. Using it as the basis of bootability for this purpose works flawlessly and identically to MS's originals [from whence they came!].

In any case, the referenced link doesn't answer my specific question: Does a bootable DVD work the same way? Or is there some alternative method for making bootable DVD's from Bootable CD's?

I will be setting up another machine with a Plextor 740 and a stack of DVD+R/W disks to eventually find out, but does anyone actually KNOW what DVD complications, if any, exist?

In the shorter term, is there any OTHER place I have to change the reference to where the SVCPACK subdirectory is located other than the obvious line within SVCPACK.INF? I assume this would allow me to burn a complete CD [The T30 has a DVD-ROM/CD-R/CD-R/W drive] that fits while the SVCPACK directory would otherwise overflow the ability to fit on a single CD media, etc.

cjl

Link to comment
Share on other sites

Slow down - I won't go into my credentials, but I've use this method for years, and it works. It does create a valid, working setup disk, and the Windows setup routine is not case sensitive.

Also, the routine I mentioned uses mkisofs to create the CD file structure, which does create a CD structure that XP setup can read without problems no matter what DOS or another .iso reading tool may say. For example, look at the structure of the mkisofs CD image from within WinRAR, then look at the same .iso from within ISOBuster. Note that you'll see two different things - XP's setup routine sees the filesytem on the CD as WinRAR does (which appears fine), not literally, as ISOBuster shows. As long as your original source tree is setup correctly before running mkisofs against it, it WILL work fine setting up Windows.

Link to comment
Share on other sites

Please do not get offended, but please re-read what I said in the previous post:

I have successfully used the method described by The Elder Geek and Paul Thurott and others, which uses the boot img from any recent MS release CD. The resultant CD works fine because there is no change from the original.

This does NOT mean that there aren't equivalent methods that also work, just a certain sense of "authenticity" not one is "better" or "worse".

That said, it IS possible to have the disk actually not completely match MS's files and *still* "work" but in fact be found to be a non-match if one brings the disks to a system where case sensitivity can be checked for. [isn't that even a standard option of XP's search? That would mean that you could contrive a search option where you would get dis-similar results.]

ISOBuster plays no particular role in the creation of the CD as I described; there are alternates that will also extract the same file in a way that is useful for making descendant bootable CD's with the likes of Roxio or Nero. The only point is that ISOBUSTER is one available way to use Microsoft's designated El Torito loader as opposed to a re-invented wheel that for all I know could be superior in certain circumstances. [For example, the two methods could differ in situations such as marginal read errors where one could retry a read error better than the other, etc.]

Since MS created a standard for loading the image on the CD, clearly any method that equivalently defines the environment should work just as well, but why should I have to care since the original is readily available? A corollary question: Is it possible that the Bart people are doing this a "long way around" because, in their circumstances, it is better for them to distance themselves from as much Microsoft code as possible, which should be meaningless for people such as me?

If all methods *do* produce the same results, then why should I opt for something that has demonstrable minor faults merely because you and others don't have a problem with their method and arguably can point out the differences, although real, aren't material? It would appear that essentially these methods are a "tie" for the short-term unless I am missing something.

And finally, can you give any indication that either method is different when you attempt to apply it to DVD images as opposed to CD images. I have never done DVD images having never before having the hardware available, but I will hopefully soon be changing that. I am asking if anyone has direct DVD experience so I can know if there are any traps here, etc.

This is not a direct response to you, but Paul Thurrott also used this line of "defense", i.e., that "it works" is good enough. Yet, using programs such as TREECOMP, it is clear that making his disk differs from Microsoft's. [Note: This is NOT a comparison to anyone here! Thurrott's mistake is that he ASSUMED that SP1 and SP2 disks are IDENTICAL to original release disks, which is just not the case! the original CD's are ISO and MS-DOS compliant, while the SP2 disk clearly is not! Assuming the disk was being used in a situation where these directories actually matter; I doubt if they are NEVER used, just are SELDOM needed for most installation purposes, then his method would clearly fail! Hopefully, the recommended method merely differs in the CASE of the named folder/file and thus is relegated back to the "authenticity" lesser argument, etc.] Having been exposed to this sort of "don't argue with me, it just works" lack of reasoning from others sensitizes me to want a better explanation if possible.

I am confused by your example about what ISOBuster would "see" in the image as you suggest. It just sounds to me that to make XP "happy" with the file structure, the method described imposes a Joliet layer on the files. Within ISOBuster, if you looked at the ISO level, indeed the names would be different because ISO cannot support the names if lower-case is being preserved and/or there are length considerations. I have checked the SP2 disk and only the former applies in this instance. But if you also tell IOSBuster to look at the Joliet layer, indeed you see the files as XP would see them, complete with the lower-case names that Microsoft DOES NOT USE in their released SP2 disk. Or, since I admit I am guessing on what you obviously have experience with, the Joliet layer shows what the original disk didn't need a Joliet layer to achieve, etc.

The rules of ISO9660 allow 16 character upper-case names, as long as you avoid the use of "-" which must be translated to "_" and afaik this is the only sore-point beyond the case. To my knowledge, MS files will conform in this regard as well, thus one can conclude that an "ultimate" method shouldn't have to introduce such as "wrong case" or any other aberration differing from original disks. Thus, my point, albeit minor, and of course based on my guessing where I will defer to your experience, is that why should I have to compromise at all, assuming an available method gets me to that "better" [in the minor way only; otherwise identical!] result?

[Note: If it turns out that the Bart way produces a bootable DVD and the MS code CANNOT DO THIS, clearly that would be far more important! But bootability issues are different from file structure differences; this would imply a theoretical slightly alternate argument to maintain MS conventions as much as possible as compared to doing as little as possible that still "works" etc.]

cjl [Not trying to offend anyone;just very inquisitive!]

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...