CLASYS

Your juvenile and egotistical trolling behavior noted, I will leave nothing out that matters.1) The subject is what belongs in the SP 2.x. The IE updates are an already discussed subtopic of that topic. That you missed it is your problem. Don't waste everyone else's time because you weren't there when the people who put EFFORT into the project was there. In short, talk is cheap and in heavy supply from you! 2) I don't need to repost the information for your benefit. I'll let the people WHO MATTER deal with the topic as it stands. Clearly, you don't fall into that category, because all you do is whimper about why your homilies and generalities aren't being addressed while I bring up an already discussed valid subtopic already introduced into this forum long before you were a member. 3) My reference to post count is directed SPECIFICALLY at you. You have far more posts to this forum than I, Gape, erp, MGDX combined. It is an indicator of nothing but potential bloviation statistics. Rather, it is an indication of just how much work people who actually DO something can get done in a minimal post head count, etc. 4) Your misunderstanding of the topic of this thread in this forum is nothing but disruptive and self-serving. My latest contribution to this thread is that I want to discuss AGAIN the topic of potential inclusion into the SP 2.x for which in the past there HAS ALREADY BEEN some support and some legitimate points for and against raised. It is a FACT that this discussion is part of the thread, the rest is your egotistical delusion about deciding what does and does not belong from the vantage point of a johnny-come-lately who wants the group to kow-tow to you, when in fact the opposite is true, etc. I seek no fame or glory for anything I did in the past or might do in the near future, just not to be insulted by ignorant remarks such as come out of you. I again call for some USEFUL discussion on the topic of inclusion of the IE 6.0 SP1 and its multitude of updates, for which I am hoping SOMEONE ELSE has a more authoritative list than I do, since I have no updates at all past I believe August, 2005, and undoubtedly there has been some possible recent MS activity to add more to the list, and possibly others have discovered still more updates beyond the ones I indicated so many months ago. If someone will post the article numbers of recent articles WHICH I CLEARLY DO NOT HAVE and have had no time to research having been RATHER BUSY since this summer up to only a few days ago, I would appreciate if we can aggregate a proper list of ALL of the relevant updates. I for my part will contribute any I do NOT see on the list that I refuse to start. If there is no support for this topic, my posting the 36 "old" updates isn't going to change anything, and I will withdraw the topic, etc. I will be disappointed if so, but not left hanging since my crude method is adequate for the few times I need to invoke it. However, I do wish to point out that there has been support for this topic before, and I wasn't even the person who started it back then. I believe there were people in several camps: 1) Do nothing at all, leaving us with 98SE with IE 5.0 unmodified. 2) Update all that applies to IE 5.0 but no further. I believe this is what the SP 2.x currently does. 3) Update only to 5.01, because apparently there is more than first seems to be inherently in a point release; there are applicatins that require 5.01 or higher, not 5.0 or higher, etc. As a subset of this, update to all SP's that belong to the 5.01 release. 4) Update to IE 5.5 and likely as far as that can be taken with regard to SP's from MS. I can point out that this is the highest "non-problematic" release of IE and there are some compelling arguments to take us to there and no further. 5) Update to IE 6.0; this is NOT to be confused with IE 6.0 SP1. 6) Update to IE 6.0 SP1, presumably with all known official patches to it. Personally, I am in the last camp, but I wouldn't be opposed to the IE 5.5 camp being what is included in some variation of the SP 2.x The discussion also addressed the fears of some that to implement any of this might make something already of some size even more unweildy. I think Gape himself was involved with an implementation strategy whereby whatever someone wanted was to be an optional separate package to be downloaded optionally, thus in no way inconveniencing anyone who doesn't want this. IMHO, it's time to re-open the specifics of this sub-topic. It is SUFFICIENT that since it can be done, a service pack can address any and all of these issues. It is consistent with Microsoft's own policy, and the seeds of the idea are already within the SP 2.x with the inclusion of updates to IE 5.0 that take it beyond the initial release inherently in 98SE. Clearly, there is no ABSOLUTE line in the sand on this issue, etc. I agree that this issue HAD to be tabled last year, because it is clearly more important to have the bulk of the SP done as a much higher priority than this admitted frill. That said, I suspect one could argue that some of what has already been added to the SP 2.x is ALSO a frill! Anyone with some CONSTRUCTIVE questions about just what this involves is welcome to participate. All others know where they can put what part of their anatomy, etc. cjl

Second you accuse Petr of going off topic when in fact the one that is off-topic since the beginning is you, as this thread is about Gape's service pack which is not concerned by IE6 updates as far as I know : Actually, my dear eidenk, it is YOU who are the troublemaker. I will elaborate:What actually came FIRST is all of the following: MANY people contributed to the service pack 2.x release as it stands now. I am happy to say I am one of them. Specifically, if you would care to look within the installation notice when you install it, you will find specific reference to me as a contributor, and not just someone such as yourself, who appears to think this forum consists merely of what you stumbled upon, not the long list of contributions by many who predate this entire subtopic going back now about 11 pages. Certain of us "have a life" and as such, sometimes we cannot devote enough time to this forum and would rather ignore it entirely until such a time we can devote proper attention to it. This applies to significant others on this forum who are even larger contributors than I am. [bTW, count of messages posted is NOT an indicator of any measure of contribution to this project; additionally this does NOT include PMs sent between members, some of which applies in my case with some of the other "principals" of this project, etc.] As such, I re-announced myself, as did others who know me. We all felt the project needs more attention, so here we are. I introduced the topic of what IMHO is an open topic for discussion still unresolved. In this case, it is yet again bringing up the notion of updating IE/OE with its well-known [to members of this forum back when a lot of the grunt work that became SP 2.x was being performed] long list of updates. There was a discussion about this; essentially it was tabled in favor of getting the main event done, which is sort of where we are now. Thus, I felt it was a good time to reintroduce the topic. Apparently you missed that discussion. As such, you don't have a right to criticize just how others make reference to it. It's all in the back pages of this forum. I already indicated that. It's up to you to find out what YOU missed, not mine to inform you. Towards that end, I indicated that I may be able to recall the KB article of one of the problem cases if I find the time. Having to deal with your intrusion into this forum with no desire to catch up on old topics well known to some of us is taking up some of that time. I also asked if some relevant others, such as erp or MGDX could recall the relevant articles, since perhaps they are better equipped than I am to recall such things. I admit I am overwhelmed in this area, since I am attempting to keep track of at least all of the following: Hundreds of updates to WinXP Service Pack 2 Hundreds of updates to Win98SE Hundreds of updates to WinME dozens of updates to IE/OE Sorry if I cannot be the master of my own domain. This is why I come to a forum, to both contribute and learn. Learn by my example, and familiarize yourself with what's already been said so as not to waste the time of people here who have already put a lot of effort into this project. Oh, and the list of "merely" 36 updates? The reason I use the number 36 is because back when I had more time to follow the list, back about 3-4 months ago, that was the number that applied THEN. I could only venture a guess as to how many more there are. I am hopeful that others, not you, have taken up this particular baton and know how many more to add to that number. I would really like to have definitive answers for any potential "newcomer" updates, which I would assume is a relatively small number, but currently unknown to me because I simply haven't had the time, up until now, to even be a responsive member of this forum. [Note: I have been active in other forums, including other MSFN forums, but my attention just got too stretched to cover all the bases; for that, I apologize for circumstances only partially under my own control, etc.] As to attempting to use Petr to advance any theories about me, I will address him separately, as he is not you. There seems to be a confusion about installation of hotfixes generically as opposed to the IE/OE-specific problem. Petr posted a bunch of 98FE hotfixes as an example of what he knows. There is nothing wrong with that; he is basically admiting what he DOES know. However, since the subject of THIS thread is what belongs on the 98SE service pack, clearly his list belongs elsewhere, and specifically there is a nice thread where it DOES belong sticky to this forum. However, Petr's information doesn't address a long list of hotfixes for IE/OE 6.0 SP1 specifically, so I will assume he has little incremental information regarding this particular sub-topic. The inclusion of IE 6.0 SP1 and its updates within the SP 2.x is IN FACT an ORIGINAL subject discussed months ago and predates any discussion of 98FE at all! IMHO it needs to AGAIN be addressed now; I did NOT merely raise this as a new issue, but rather as an OLD one that needs to be rethought. If no one wants to talk about it, that's fine, especially when I have come up with a [barely!] acceptable method of dealing with this problem, which I believe others are also interested in. You have a curiously out-of-context quote of me that references two specific updates that are CURRENTLY part of the SP 2.x. You make it sound like I invented them as well. In point of fact, they were discussed among the "senior" members of this forum. They were, but no longer ARE, sore points that highlight the fact that Microsoft's hotfix installers are sometimes broken. At least one of them also interacts with the installation of, among other things, IE/OE 6.0 or IE/OE 6.0 SP1. The SP 2.x addresses these and installs them correctly AFAIK. I can confirm personally that one of them does install correctly because the problem does NOT lie with the underlying hotfix files, but rather with bugs in Microsoft's installer program within the hotfix; the SP 2.x simply does not use that broken code, thus gets the job done by a functional equivalent method, etc. Clearly, the discussion of these two updates is directly on-target for this forum, but also are not specific to the subject of IE/OE updates. You insisted on some hypotheticals being discussed; I pointed out cases where reality differs from theory, one of the many subtopics discussed on this forum successfully, and at this point long put to rest and need not be discussed further unless someone, other than you, wants to post additional information. For myself, I do not wish to, since it is available in the forum's back pages, as a resolved issue. It is sufficient I raise existing examples as to why what you posted could be questionable, etc. I'm glad you admit to "AFAIK" with regard to the IE/OE SP 2 inclusion topic. Clearly you should admit you don't know. The problem is that those of us who were here when a lot of subjects such as this were discussed DO KNOW. Do you think it's fair to impose your not knowing on us who do know merely because you didn't participate in the discussion and we did? I apologize if I cannot have photographic knowledge of the back pages of this forum, especially considering what I am dealing with for myself, etc. However, as crude as it might or might not be, I understand one can research material already discussed on this forum. Perhaps you can enlighten us as to how effective it actually is to do such research? cjl

While there are updates claiming to be for Windows XP Service Pack 2 and thus IE 6.0 SP2 specifically, and claim to be cumulative, they are NOT all totally so. There are one-off updates not addressed by these accumulations! In any case, this is not the subject of this forum, nor of this topic.Your list of updates to 98FE notwithstanding, the subject matter of this topic is updates to IE and OE that need to be applied after installing IE 6.0 SP1, and show verification of installation by observing the help/about in IE. There are at least 36 such updates. It IS true that some of these updates are theoretically cumulative. In fact there are at least two such accumulations: One for the updates to IE and one for the updates to OE. With regard to this, it might be true that the latest version of a member of an accumulation list might in theory replace any and all of the predecessors within that accumulation. Thus, an argument could be made that no one update is cumulative for all purposes. However, it is ALSO true that the two updates one could nominate are also insufficient to update IE/OE completely simply because some of them are one-off in nature. [Note: Update 870669, while nominally related to IE, is considered an MDAC update and appears in add/remove programs as such. I am NOT referring to updates such as this, but I believe this is a singular case.] Some of these updates are obscure, but are nonetheless available and should be applied to IE/OE. To my knowledge, all of the updates considered cumulative for IE or OE have at some point in time been available within Windows Update. Also, to my knowledge, NONE of the non-cumulative updates have ever been mentioned within Windows Update. Since Windows Update represents such a small percentage of the source of updates for Windows 98SE in its entire history, this is a meaningless point! Indeed, this forum is devoted to the polar opposite, namely the categorical failure of MS to provide available updates in any meaningful way, etc. So, I would suggest to anyone who wants to contribute anything to this thread, can you please provide any actual on-topic experience with this multitude of updates, as opposed to optimistic hypotheticals or alternate examples of unrelated topics. My methods are crude by my own admission. However, they also succeed at the intended mission. Anyone that can simplify the method down to something that gets the SAME job accomplished with less overhead I would gladly defer to. Additionally, if someone has information about more than the 36 I am referring to, please post their article numbers here. cjl [can provide the ones that I am aware of; none were hard to obtain at the time I got them. Can't say about now!]

How would it cause certain updates to not install at all ? Can you be more specific by actually providing an example instead of theorizising so much. As far as theory is concerned, KB updates are supposed to do several things. They first check if the IE version is the one intended as target, either 5 or 6. It it's the wrong version they won't install. After that they eventually write registry entries (killbits for example) and replace files. If target files are not in use they are replaced immediately if they are of a version inferior to the one that installs. If they are of a version superior to the one that installs, they will be skipped by the installer. If files to be replaced are in use, wininit is used to replace them automatically at reboot before the OS loads. Data is appended to wininit.ini. Wininit either does not normally downgrade files unless the file to be replaced is first deleted by using the NULL command which the KB installers do not do as far as I know so that even the install order should be insignificant as far as replacing files is concerned. For someone intent on me not "theorizing" you seem to engage in a whole lot of it!As I stated in an earlier post, there are the INTENTIONS of updates, and there are the REALITIES of updates known to this forum to SIMPLY NOT WORK AS INTENDED. Unless you actually installed the 35+ updates to IE 6.0 SP1 and can state some EXPERIENCE, I suggest you practice what you preach! What you have not addressed is whether or not an update simply bails out because it is "unhappy" with the environment it's run in. IE updates seem to have this quirk in some instances. What you suggest is generally the behavior of Windows updates, which need to have the default of rebooting after installation inhibited, if possible. Please note that 98SE doesn't have a "QCHAIN" mechanism, allegedly a working functionality within the NT family. It is well known that specific cases in the 9x world simply don't work as you imagine, and a few have been discussed on this forum. [in a prior post in this thread, I outlined two of them, although I would have to research the KB numbers. Perhaps Gape or erp or MGDX can give the specific references. I may be able to find at least one of them, but frankly, this is old business of this forum and not up for debate, etc.] MS occasionally screws up the logic within an update's installer disrupting the "rules" such as they are. In my experience, several of the IE updates are subject to this, thus the need to reboot in at least a few cases, etc. Can anyone actually show an install that succeeds in installing all of these IE updates. [Note: NONE of these are updates to Windows 98 or Windows 98SE or Windows ME]. cjl

I wish it were true otherwise, but that does seem to be the case! The versions of the hotfixes for Win9x apparently are just too broken to correctly batch together.It is POSSIBLE to create a limited number of batch files, each requiring a reboot since they end with an update that requires it. This would avoid the need to reboot after EVERY update, but not after the updates that actually require it, etc. However, I haven't spent the time finding out WHICH of the updates actually require local reboots; my toy method avoids caring at the expense of unattended real-time being spent, but does guarantee successful installation. If you have access to all of the 30+ updates and are inclined to check this out, try applying them by hand while avoiding a reboot in each and every case; you will then see the updates that refuse to install. Applying override switches to force an install will also fail; the files won't be updated and IE Help/about will NOT show the update as being installed, etc. I can provide anyone the entire list of updates; some of them have become obscure. Please note that more than a few were NEVER a subject of Windows Update! [Note: I only follow IE 6.0 SP1 updates for Win98SE or ME. In Windows XP, there are NO updates for IE SP2, rather they consider all updates to be applied to WINDOWS XP itself.] cjl

You too, erp! Hard to believe, but both of us are about to come to our FIRST ANNIVERSARY with this forum! cjl [sometimes it feels like a lifetime!]

You certainly do not need to reboot 30 times to install 30 IE updates in a row. Installing the thirty of them in the correct order and rebooting once should do I think. No, that is absolutely incorrect. Apparently you are unaware of the interactions of some of the updates. They simply will not install unless there is an actual reboot. Not all, of them are this way, but some of them are. My methodology is to use a state machine that remembers where it is across reboots that winds up in the STARTUP group and then removes itself when done, etc. This allows all updates to mindlessly reboot even if one of the cases where it isn't absolutely necessary. But no, it is not possible to do a simple batchup of all of the updates forcing a non-reboot after each install, as it would cause certain updates to not install at all. I am unaware of whether this is by design or by accident. Certain updates clearly do have a designated order, and it's when using that order expressly that it fails to install as there are dependencies as written, etc. This is why I would like to see an optional modular section to the SP2.x where if you specify the service pack should install the equivalent AND you have separately downloaded the actual update files, the IE update can be performed by the Service Pack on demand. This affects no one wanting to ignore IE, yet allows all of us who need it to update IE to also have what's needed, etc. I would suggest some form of command line or .ini file modification to specify where the IE package separately exists, or perhaps if the executable of the service pack merely notices a magic-named file in its own directory path, etc. Done this way, there is no net change in the size of the SP2 download, etc. Please note that while what you posted is the theoretical notion often claimed in Windows XP [and sometimes broken there!], it is NOT true that all of MS's installer packages for hotfixes actually work correctly. Some of our ongoing discussions involve the specifics of broken hotfixes, not the usefullness of the underlying files needing to be applied, but rather that as provided by MS they simply do not "cooperatively" install properly, etc. For example, there is a hotfix that will NOT install unless IE 6.0 [not SP1] or newer, and perhaps some other hotfixes, hasn't yet been installed. The simple answer is that the internal logic of the hotfix installation package is plain broken. The underlying files can only be applied in one of three ways: 1) The hard way [update them by hand] 2) Use the hotfix as provided by MS basically early on after a fresh install of Win98SE and clearly before any of the later updates that prevents it from functioning due to its own internal bugs. 3) Use the SP 2.x which correctly places the proper files in all cases. MS never fixed this hotfix which, unless used before all of the other updates involved is applied, actually just bails out and self-ends without doing anything whatsoever, no messages, no actions, etc. Fortunately for all of us, the SP 2.x properly applies the files contained within this broken hotfix and avoids this entire problem while providing the benefits as intended, etc. There is another problem case where should a certain hotfix be already installed, all of several newer ones that update the same file will fail to update the affected file. You wind up with a file newer than a fresh install, but not as new as newer-still updates want to provide, etc. I sent Gape a copy of the problem version from MS, and hopefully the SP 2.x now will override this weird behavior correctly. Fortunately, the problem update itself is somewhat obscure [although I do have it!] so hopefully few are affected by it. But, as I understand the mechanism of the SP, this problem is also avoided when the SP2 is applied despite broken logic within MS's provided hotfixes you have [likely unwittingly] given too much "credit" to, etc. One of the purposes of the Service Pack is to AVOID this entire problem since the Service Pack is its own installer of all of the underlying files all at once. The idiosyncracies of each hotfix's potentially broken installation procedure are totally avoided. Additionally, some of the underlying files are NOT available any other way, since in some cases they are located in overly complex packages only, and have been provided from these, etc. because the theoretical specific hotfix is simply not available. The SP essentially accomplishes what theoretically some unavailable packages might have, regardless of whether or not such packages may or may not have had difficulty installing their files or in some cases even existing at all! So, the SP 2.x causes there to be no consideration of what the "correct order" even is, as it will arbitrate an order that causes it to correctly install all subfixes for any problem it addresses. And in this instance could avoid a situation for which there actually is NOT a "correct order" at all. cjl

Hi people! Been really, really busy, but back to offer any relevant input. My personal wish list still includes a few things: 1) How to add IE60SP1 support into the SP 2.x even if only as an optional add-on. This would mean that those who are put off by bigger downloads need not worry. In fact, perhaps the current setup could be modularized somewhat so a "lighter" still version could be had [for those who already have much of it? I believe the AUTOPATCHER XP people have something like this]. [see below for my personal "bandaid" to this IE60SP1-specific problem.] 2) The ability to update all of the information that the QFECHECK program wants to inspect regarding the fixes themselves. This helps to find accidentally corrupted updates that then fall below the minimum levels the fix demands, etc. If necessary, this could be an add-on package that inspects your system for equivalency to the fixes themselves and declares them "installed" since they conform, etc. Registry information could be created in sync with installed updated' requirements, etc. [isn't this, in essence, what the SP2 does, namely replaces the need to run all of the loose fixes? QFECHECK was designed to confirm that it was performed correctly and thus would be a helpful confirmation that all is fine both right after the SP2 install and also later when perhaps things go awry.] 3) A small point about the QFECHECK program itself: There is a need to know the difference between the demands of minimum revision of the installed hotfix itself versus the possibility that the installed version is even higher than that [presumably because some other update wants it that way!]. It would be nice to have a smarter QFECHECK that could indicate this difference. As a kludge regarding the IE60SP1 update problem, I have written a toy batch file that is a bit crude, i.e., has hard-wired directory requirements that conform to my local norms only, etc. It uses a freeware REBOOT program so that mindlessly any IE patch can be unattendedly installed without knowing or caring whether the patch requires a reboot [clearly SOME do!]. A big criticism is that it ALWAYS reboots after each patch even when you could prove that some don't need to, etc. [Lazy, but effective.] As of my last update to it a few months back, there were about 30+ updates to IE60SP1. I know some of them theoretically replace each other, but: i) I don't know authoritatively which ones truly supplant which. ii) There definitely are some that are not replaced; this stuff is NOT always cumulative, even though there are two main subthreads which claim to be so ["cumulative updates" for IE and OE], there are other issues neither subthread addresses. iii) Some of the updates have bizarre interactions with 98lite that can only be solved by predictable installation habits. I can give a fatal example here: If you contemplate using update Q330994 [or some of the more recent cumulative updates that replace Q330994] and you are using 98lite either SLEEK [V1] or CHUBBY, there are procedures you must follow that involve one of several alternative methods [i personally use the method of installing IE60SP1 and its patches in SLEEK [V1] and then later optionally change over to CHUBBY afterwards, never again to make any further changes of shell type.] that will work if you do it carefully enough then immediately install Q330994 [or its descendant patches] but only after installing some prior IE updates. If you fail to follow these overall directions, you will be left with a hopelessly broken Outlook Express that can only be repaired by removing all aspects of IE [preferably with IEradicator or just use 98lite SLEEK [V1] again, etc.] and do it by one if the ways that works. All of the methods also require multiple installations of IE until you have obtained an install where you can choose "Just reinstall all of the components" in the custom install *AND* no further shell changes. [Note: I do change to CHUBBY shell and thus I yet again reinstall IE until I get the message during its install. In the ME variant of 98lite, in this situation, I may have to install IE FOUR TIMES to get it right!] Clearly, this process has many potential pitfalls; it's useful to have a procedure to do all the updates to make sure you get the whole thing right! [Again, this is an unintended interaction with (98SE OR 98ME) AND 98lite AND IE60SP1 AND (its various updates) that was totally fine and non-critical until Q330994 was released, which broke everything! I brainstormed all sorts of attempts that *SHOULD* have worked, but this is the only way I found that *DOES* work!] iv) After you install the SHELL32.DLL update in Win98SE, you get notice of this within IE Help/About. Installing all of these other updates show 30+ additional updates there, so you get a REALLY long list of installed updates [impress your friends!]. [Note: XP SP1 has abandoned this practice after about 20+ updates, so all of the newer updates no longer show up there, which is confusing since you now can't readily tell just how many newer ones you've added, etc. XP SP2 doesn't ever update this beyond the SP2 notice instead depending on QFE information elsewhere to report as a Windows-XP-SP2 fix, not one to IE or OE. Using my kludge in SE or ME, the entire glorious process is readily displayed.] I can make the thing available if anyone wants it, and/or copies of all of the 30+ updates, some of which may have become obscure. It takes quite awhile to run due to the 30+ reboots, but it *IS* totally unattended! [And someone may want to clean it up so it's more generic to others' systems!] cjl [Glad to be back, albeit still very busy!]

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!]

So, the simple answer is that: 1) Hotfix integration is a convenience that works only if it works. If not, use an alternate method to get the hotfix into SVCPACK.INF. The hotfix beta 1.0 tool is probably fine, but if necessary do it by manual edit, etc. 2) QCHAIN functionality is meaningless during an install within an image; only applies to batch files run after the install is complete [or perhaps *almost* complete?] 3) Hotfix integration should be added in reverse chronological order to ensure that the SVCPACK.INF file has the file list re-reversed back to chronological order within the image. Is this correct? cjl

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

I am aware that a batch can be run LATER to add in all of the hotfixes, as each release generally is good enough to be able to self-update with regard to just about any hotfix. [The last time this wasn't true is if you needed to install on a disk larger than 127 GB and you didn't have SP1 integrated in already!] The point is that I believe there is conventional wisdom that the ONLY thing "wrong" with the MS /integrate method is the sore cases such as 885250 I think it's called because of the inherent anomaly of the updated files inside, etc. It would appear that these two pretty new updates have some other sort of internal flaw associated with the /integrate function itself, such that if other updates are already integrated into the install image ["too many" whatever that number is, I apparently have exceeded it!] then they will refuse to integrate via that method, instead crashing in the attempt, yet install fine if these updates are added before so many of the other updates are added, etc. But since the overall recommendation is to add in the integrated updates in chronological order, this means that these quite new updates are generally added in relatively "last" etc. A related question: Is it REALLY necessary to have them ordered? Or is this just a matter of time efficiency? I thought that as of SP2, the "QCHAIN functionality" is built-in, thus order would appear to be superfluous? Does it fix it up regardless, or am I missing something about some interaction elsewhere? Also, please note that if you use the /integrate method to build the lists in SVCPACK.INF, the lists are updated chronologically; the NEWEST updates are at the top of the list, etc. Isn't this precisely the OPPOSITE of the recommendation? Thus, the "correct" way to build the list would be to have a REVERSE chronological batch file of invoking the /integrate method placing the EARLIEST update at the top of the lists within SVCPACK.INF? In any case, you can lift the body of a batch file from inside of SVCPACK.INF to become the guts of a post-install batch file to be run at the first log-in or later that will have all of the /q /n /z switches set on all of the invocations of the name-shortened kbxxxxxx.exe forms of the fix files, etc. cjl [attempting to rise above newbie status in this forum!]

I have an update on the problem: I added still more integrated hotfixes via the /integrate:<path to image> method, and the problem didn't worsen. Apparently, this problem only applies to two specific hotfixes, both fairly recent: 900725 896688 which I tend to integrate last due to their being pretty new. Again, all works fine if I INSTEAD use the hotfix tool beta 1.0, but using the MS method it crashes merely because there are quite a few hotfixes in the image already, etc. [Currently, when the problem arose, I was attempting to put in about 12 more hotfixes than the set associated with Windows Update; there really are a whole lot more than those available! Also, I saw the need for some of them to obviously be a part of Windows Update, but they weren't added until more recently some of them have been added. But, as of this writing, there are even some that are the subject of recent security bulletins that still aren't in Windows Update! I can't believe that this should somehow "invalidate" them relative to hotfix integration, etc.] Installing a system from the image seems completely fine; this is just an observation of a problem with the /integrate switch within these two hotfixes and only in this narrow context; it formerly worked when there were less prior-installed integrated hotfixes in the image. I am using a batch file to create the larger amount of those other fixes applied to a clean image. Just using the RUN command to use the integrate switch on either of these two makes it blow up in this circumstance, etc. So clearly, the use of a .bat file isn't the problem, etc. any ideas? cjl

"There is also a great page at the site with all of the hot fixes in there as well as the silent install switches for each one!" Can you point me to this? cjl [registered member there; my company, etc.]

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

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

I am just attempting to use the WindowsXP-KBxxxxxx-x86-enu.exe /integrate:<path to image> method repeatedly to update a vanilla image of XP SP2 OEM with about 60 or so hotfixes. [i am using the hotfix tool beta 1.0 for the "hard" cases like 885250, etc.] All hotfixes are being added in chronological order. As I add in new ones, the last ones added [it's in a batch file, but that isn't a factor; once the others are present, it won't work even if run manually from RUN, etc.] stop working. Batch file aborts; wants to send to MS, etc. Is there an "upper limit" on just how many hotfixes the /integrate method allows? Fortunately, the hotfix beta 1.0 tool seems to add in those final ones anyway, but what gives here? cjl

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

I apologize if this is a newbie question, but I have noticed some differences between say taking XP PRO OEM and slipstreaming with SP2 /integrate, and just using VRMPOEM as the basis for adding hotfixes ultimately to make an .ISO and burning it. Along the way I have a few questions as well. First of all, I have noticed that there are driver differences between the released VRMPOEM and the WXP OEM slipstreamed with SP2 /integrate. The differences I noticed revolve around first the total absence of drivers for some VIA USB 2.0 hardware that are "advanced" to instead a defective driver for the same hardware. Clearly, something was done not covered by the 266MB downloaded SP2 as opposed to the RTM XP with SP2 imbedded, etc. [i can elaborate on this VIA problem if anyone wants, including how to solve it which involves a VIA-supplied fix only recently available! Arguably, we were better off with NO driver than a flawed driver, etc.] Additionally, the released VRMPOEM gets you subtle differences in the files as compared to slipstreaming the integration of SP2 over the original OEM disk. This has to do with the EXACT file/folder names, and is arguably cosmetic, but none-the-less different. When the original XP OEM disk came out, all file and folder names passed ISO 9660 level 1 and also MS-DOS MSCDEX limitations, so there never was a problem making any form of descendent file set, etc. However, when you apply the SP2 integration, you get violations of this sensible standard in many areas. For example, many directory names are actually [partially] lower case, and in at least one place cannot be expressed in 8.3 ["networking"]. The VRMPOEM release CD is NOT quite the same, essentially being the same as the slipstream SP2 method version as long as all names are FORCED to uppercase. [Thus, "networking" becomes "NETWORKING" but still cannot be 8.3.] So, given all of this, clearly telling Nero or whatever to use MS-DOS compatible isn't the right way to burn a CD [hotfixes aside], since that directory will just be wrong. [Will truncate, not use the ABCDEF~1.EXT form as usual.] Some have used Joliet, but that also preserves the lower-casedness which makes it non-authentic. What to use and how to tell Nero to do it? Does something [some Neros have this] called ISO 9660;1999 solve this? Or is there some other way to force it without renaming the affected areas [several dozen places in a standard I386 directory are affected]. I believe all of the 8.3 violations are none-the-less 16 or shorter and want to be all forced upper-case. If this is done, then an ISO level 1 *could* handle it. But what is the easiest way to get the case forced without doing it manually? Over and above all of this of course, the looming question: For the purposes of a base image for adding hotfixes for unattended installation usage, is there any reason to use WXP OEM slipstreamed or VRMPOEM instead given both are available? Thanks for sorting this out, any assistance appreciated for a beginner! cjl

"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!]

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

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]

I guess this is the place to add some anecdotal stuff: [Note: All partitions are FAT32.] I haven't attempted to see if I am corrupting anything on the drive, but I have used some Hitachi 250 GB drives in various configurations. Here's what seems to be working: 1) Using Partition Magic, I am only able to set the max partition size to about 196 GB regardless of position on the physical disk. The entire disk can be referenced by using two or more partitions. This limit is imposed running Partition Magic 8.02 on Win98SE, WinME or WinXP. The physical disk has only been accessed from XP if hooked to the IDE connector on the motherboard: Tyan S2466; made no attempt to use from 98SE. Alternate configurations: USB 2.0 and/or Firewire external boxes. These seem to work everywhere including the DOS Firewire IOmega drivers from Ghost2003. I have tried 32 and 64-bit firewire cards and the IOmega driver works fine from DOS. The similarly-supplied USB driver has lots of problems: Won't support disks bigger than 127 GB at all in DOS, and additionally hates some USB cards entirely. No problems with Firewire in 98SE, ME, XP, DOS with the IOmega drivers. Works in Sony Vaio laptops, random Via Firewire PCI cards, and even a 64-bit SIIG which runs major-way faster in DOS than when placed in a 32-bit slot on the Tyan S2466 [which has two 64-bit slots and the rest 32-bit.] Thus, the driver likes all of the hardware and any size disk, etc. Yet, Partition Magic still won't let me make a FAT32 partition bigger than 196 GB, and I generally use two 120-odd ones thus I am avoiding the problem in 9x, so I have no answer about data corruption. Last configuration is using Promise Ultra-133 TX2 which totally just works for adding plug-and-play non-boot disks using Promise drivers for 9x or XP. If you add the driver for XP into the mini-kernel, you can even install XP on one of the Promise-controlled drives. But with no drivers, DOS can completely access everything, and 9x with the supplied .MPD driver no problems at all. [Note: The Promise card has a BIOS chip on it that does all of this!] It can run in 32-bit mode or double-speed 32-bit mode if you have a double-speed motherboard such as the Tyan S2466. [Note the SIIG firewire card gets the speed not by doubling the bus speed, but rather that card is a 64-bit wide card on this same motherboard, etc.] So, I am booting to a sub-120 GB disk and the driver talks to the 250 GB disks and I seem to have no problems with any system! So, if I raise the partition size to beyond 127 GB, I can assume that would break the data and should be avoided? cjl ps: Now that I think of it, I did trick FDISK into making a full-size disk by first making a 7.8 MB primary, then extended for the rest of the disk, then a giant logical partition, then used Partition Magic to remove the primary partition, etc. Any attempt to change the size of the remaining partition set off Partition Magic to insist I down the size to about 196 GB. Additionally, when I hooked this disk up in a USB 2.0 box partitioned that bigger way, Win98SE showed two copies of the drive in My Computer!!! [Yes, i was seeing double!]

Just did another install of XP [sP2 slipstreamed] and now [once seen a long time ago; had forgotten this] I see strange indicators in the options such as the View Folder Options: Display the full path in the Address Bar-ON The "-ON" or "-OFF" is redundant to the checkbox setting as you come into the options box, and changes if you make changes, but only after you close and reopen the options box, etc. Is there some sort of registry debug setting in place for this? cjl (want to get control of it)

I agree somewhat.....I really like 98se and with the tweaks I've done all seems pretty smooth. I maybe have 1 lockup a week or so and I test A LOT of SW on it! FYI for XP, I have been able to totally turn off the file thing that when you delete a file, it returns...there's info out there how to do it but I had to then boot to 98SE and replace the file in a few locations....so on that notebook I have, never recopies a delted file!! Yeah!!! I also formatted the hd with fat32, not ntfs.....(maybe that's whay it's slower in xp, but I can't understand why such a difference, still). <{POST_SNAPBACK}> In my experience, XP works BETTER on FAT32, and I really don't need ADS crap bloating my file system. Look at an "empty" NTFS drive as compared to the same size FAT32. More importantly, if the system runs afoul, I can use DOS-based stuff to fix it, if not Win9x-based stuff as well. Case in point: Thought I had a cleaned-up XP system. Only actually problem was that SVCHOST.EXE was actually trojaned! No program I was able to run on XP found this to be true! [including running stuff in safe mode.] Trivially located it as follows: Configuration: XP on drive C:, 98SE on drive F:, Boot.ini set to boot either. Boot to 98SE, run IE and use Trend Micro Housecall. Found it real quick. Note that Trend DID NOT FIND IT when run from the infected XP system. If I hadn't formatted C: drive as Fat32, I couldn't have run 9x, and additionally, even if I had an alternate drive arrangement, I am not certain that the 98se system could have found the problem within NTFS, even with some of the available NTFS add-ons for 9x. An alternate arrangement that also works is to put 9x on F: and XP on G:, both FAT32. This way, drive C: contains only trivial and repeatable files. You can ghost the C: drive and then just replace it at will if you suspect malware invasion. Additionally, if you use something like Norton Rescue Diskette, you can fix your system after a viral "payload" wipes out say the first 128 sectors of your hard disk and have lost literally nothing!!! The rescue diskette puts back the partition table, and you just replace the stable drive C: contents, etc. cjl (XP advantages are theoretical in a world attacked every day by spyware]