jaclaz

Good. Strangely enough the posted semi-random links had some merits. The "normal" files compressed with compress have the MSCF header (MicroSoft Cabinet File?). The ones in What.7z have the SZDD one. <- this is the "older" format. See also: The EXPAND in XP seemingly cannot get the actual "full name" on the proposed files. But 7-zip can see the "full name/extension" of one (OpenCL.dl_ ->OpenCL.dll) but not of the other (nvuninst.ba_->nvuninst). The expanded nvuninst is clearly a .bat or .cmd file. Most probably the nVIDIA installer keeps "somewhere" a list of "original names". I can reproduce the compressed archives using the version 2.00 (1992) of COMPRESS.EXE, using the -r switch with OpenCL.dll, and NOT using the -r switch with nvuninst.bat). If i compare the results of: COMPRESS.EXE nvuninst.bat nvuninst.ba_ <- this is identical to the original file with COMPRESS.EXE -r nvuninst.bat the only difference between them is byte @0x09 which in the first is 00, whilst in the second is 74 (please read as "t"), which is allright: http://www.cabextract.org.uk/ http://www.cabextract.org.uk/libmspack/doc/szdd_kwaj_format.html It is very possible that later versions of COMPRESS.EXE do exist that allow to have the same results, but it would be strange since the new, "approved" header is MSCF since at least Win 95 times, even diamond.exe uses this format, so it's queer that the good nVidia guys used such an old compressor . jaclaz

gasses and gases are seemingly all correct according to the freedictionary: http://www.thefreedictionary.com/gasses A guess is that the s or ss's are due to to differences in pressure jaclaz

I have none of the older Catalyst files and the 12.8 has no .in_ files in it. Attached is a driver (7-Zipped). Using expand with the -r switch extracts and restores the original file name. I infer that the file was compressed with the -r switch. Enjoy, John. Well, this doesn't "count". I am still after the specific .in_ file about which you startefd the thread (or any similarly behaving file). I mean, if the file attached is renamed correctly with the -r switch of EXPAND.EXE, yes, it means that it was compressed with the -r option with COMPRESS.EXE or other equivalent tool. I have plenty of files that are actually renamed properly with the -r switch of EXPAND, I was looking for one that DID NOT behave like that. Possibly tomasz86 will be so kind as to provide one. jaclaz

Semi -random thought (particularly directed @cdob ): Wouldn't a grub4dos emulated F6 floppy do (and possibly be a little easier)? And/or, instead of initiating from CD, maybe an install from USB with either of these approaches: @surfing69 Usually you need a "real" USB floppy, and it can also be an issue (depending on the actual floppy drive) see: Generally speaking (and IMHO), integrating the DriversPack Mass Storage drivers: http://driverpacks.net/ is easier that using nlite If you have an "expendable" (in the sense of losing the data on it as it will be re-partitioned/re-formatted) USB stick, you could, after having integrated the DriversPack, try with the "generic" WinsetupFromUSB tool here: and should it not work for any reason, we have still the more "manual" ways by cdob before mentioned . jaclaz

But there are hottish balls of gasses that appear in the sky bubble as small bright lights brilliant effulgences.... http://www.macmillandictionary.com/thesaurus/british/star jaclaz

It is possible that this applies : http://www.computerhope.com/expandhl.htm Would it be possible that those files are actually compressed with COMPRESS.EXE but without the -r switch? Since I presume that the whole lot of Catalyst files is huge, could you post just a single (smallish) .in_ file (inside a .zip archive) so that I can have a look at the binary? jaclaz

The usual couple of loosely - but not much - related links: http://www.msfn.org/board/topic/10801-how-to-compress-files/ jaclaz

Seemingly still open question: What about Victoria (for windows)? and already pointed out by loblo here. Maybe you can have a "compromise", using two utilities for different disks.... jaclaz

Accurate , but harriers and buzzards? A collection of them! Usually in the afternoon, assemblies of harriers and buzzards gloom the sky bubble, occasionally dimming the illumination.... jaclaz

Ok, I'll make the questions, since we have the attention of the Author of the mentioned tutorials . @Steve6375 Is the menu.lst entry that Damnation posted a "proper" one, tested by you and present in any of your turtorials or is it - as I presume - a combination of the entries of two (or more) different tutorials? More generally, do you suggest that your tutorials should be followed and replicated as they are or it is advised to take bits and pieces here and there and assemble a new way when experimenting the first time? jaclaz

Well, I was replying (mainly) to this question: The part that IMHO is not clear at all in the syntax is that the -d switch will normally work also for "single" files (and not "only" for "multifile" .cab or whatever). jaclaz

here http://www.rmprepusb.com/tutorials/firawiniso and here http://www.rmprepusb.com/tutorials/install-xp-and-win7-to-internal-hdd in the XP7PWD.zip file At least in the first one there is NO trace of Winvblock (which is OK since the tutorial is about using firadisk). The second, which is number 63 (the first one is #43) uses BOTH, BUT NOT "at the same time" or in the "same menu.lst entry", at least AFAICR. With all due respect you have some "wrong" approach. The idea of a tutorial is that of following it "to the letter", WITHOUT introducing ANY variation of ANY kind. Once you have suceeded with it, THEN (and only THEN) you may introduce changes. By loading together TWO drivers that essentially do the same "job" you are actually creating a very good terrain for a driver conflict. There is NO "better" driver between Firadisk and Winvblock, they were actually developed exchanging ideas between the respective Authors, but for mostly UNknown reason one (or the other) may work better in a given situation. Well, I encountered several, possibly because I have some more experience than you have The idea of advice and particularly of the "better be safe than sorry" one is simply that, you are perfectly free to do whatever you see best fit, the only difference is - in case of issues - that you had been told. Along the same lines, the advice is to choose one of the two mentioned tutorials (or another one) and follow the chosen tutorial to the letter BEFORE introducing "changes" or "betterings". jaclaz

The site for the Commercial/Shareware HD Sentinel: http://www.hdsentinel.com/ besides the app itself contains quite a bit of information, see FAQ's: http://www.hdsentinel.com/faq.php and unless you want to monitor the hard disk while the 98 is running and continuosly, the DOS version (which BTW is free) should work "better": http://www.hdsentinel.com/hard_disk_sentinel_dos.php Drivers suck. A reboot is not that bad IMHO. jaclaz PS: Have you tried smartmontools? http://sourceforge.net/apps/trac/smartmontools/wiki but still if the issue is smartvsd.vxd they won't work as well Also an older version of diskcheckup: http://www.passmark.com/products/diskcheckup.htm might do. Get one from here v 1.1: http://web.archive.org/web/20051228132625/http://www.passmark.com/products/diskcheckup.htm or here v 2.1: http://web.archive.org/web/20071104213917/http://www.passmark.com/products/diskcheckup.htm

Can you post WHERE exactly you got those from? It seems to me like you are loading BOTH Winvblock and Firadisk WHY? As a general rule (NOT necessarily applicable to this particular case), remember that on some filesystems grub4dos is CaSeSeNsItIvE and, still to be on the safe side, using "multidot" filenames is not the best idea, as a number of things that you may want to boot might not support those. When using grub4dos "in general" but actually "always" when experimeting, if you use all small letters 8+3 names you reduce form start the number of possible issues. jaclaz

Broken google? See: http://www.computerhope.com/expandhl.htm The -r switch should work allright, and the -d will give you the info, example (XP): expand -d usb.in_ Utilit… di espansione file Microsoft (R) Versione 5.1.2600.0 Copyright (C) Microsoft Corp 1990-1999. Tutti i diritti riservati. usb.in_: usb.inf jaclaz

I don't think that you can add those keys "directly" through TXTSETUP.OEM, but you can most probably modify the invoked from it .inf file(s). jaclaz

Of course provided that his reaction time is actually shorter than three seconds.... jaclaz

NO air, nor atmosphere, unfortunately , no sky either, nor horizon only an immense bubble (surrounded by vacuum ) of odorless tasteless gasses. jaclaz

Yes, this may be an issue. You might want to try another approach, slipstreaming the actual AHCI driver to the source (by itself or using the DriversPack) as to remove this possible issue. I am not sure to understand the reference to the SD cards. More loosely, you have a working OS (Windows 7) and a USB stick (or SD card reader?) that can boot to grub4dos, so you have in any case a way of booting. Before making other experiments I would create (on the USB whatever) a Windows 7 boot floppy image, see here: http://www.multibooters.co.uk/floppy.html For a quick howto. And test it from the USB. Something like: map --mem /myfloppy.img (fd0) map --hook root (fd0) chinloader /bootmgr should do nicely. If you need more info on how to make the floppy image (I would personally use IMDISK) , just say so. Once you have this "failsafe" provision, you can try to copy the Windows XP source to the internal hard disk and install it through WinntSetup: jaclaz

Naah , all the balloons behind the green glass door are not inflated, they use a compressor to aggrandize or swell them using a poutpourri (or assortment) of different gasses. jaclaz

Or - maybe better - get the info from the mouth of the wolf, go to the dedicated section of the board: http://www.msfn.org/board/forum/157-install-windows-from-usb/ from which at least two of the mentioned resources were originated. (BOTH using an old version, of this ). Here is the original source (in the now "historical" thread) of usb_prep8.cmd that the linked to sites used: Though of course working, that method/tool is now considered obsolete and we have several, much more "flexible/comprehensive" methods/tools. jaclaz

I have seen everything and the opposite of everything, obviously most of the passive cooled (no fan ones) are slowish/low power. <- please read as "slowish netbooks like" but there are more than a few that have more than decent performance (but usually need a fan or heat pipes or whatever). A good place to have a quick look for models is this one: http://www.logicsupply.eu/mainboards/ (mainly jetway motherboards) besides the historical: http://www.mini-itx.com/ There is also the not-so trivial issue about $'s jaclaz

You mean the HKEY_LOCAL_MACHINE\Enum\PCI\VEN_8086&DEV_7112&SUBSYS_00000000&REV_01 or an actual USB device (under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\USB or where)? That tool is limtied to PCI, by design. Can you see them with USBview (GUI): http://www.ftdichip.com/Support/Utilities.htm jaclaz

Try instead creating (notepad will do) an empty file named "usbdrive.tag" on the root of the USB device first partition. More generally the idea of a check is to check something . If the check fails it is advisable to create the conditions for the check to be successful instead of removing the check alltogether. The real question being of course WHY that file hasn't been created by the WinSetupfromUSB? Still you didn't answer the asked questions (just like checks are there for a reason, questions are asked for a reason): how EXACTLY did you partition/format the device? Or, if you prefer, are you sure that you are booting from a grub4dos MBR (and not from the PBR)? You see, if by any chance you started with a "deviation" from the "standard", it is unlikely that by pure chance your path will cross again the path of the application, the risk being finding a new issue ( to be worked around) at each new step. jaclaz

Actually, it would be easier if you could test the mentioned PCI.EXE and verifies that it can identify correctly your hardware. I mean, we have already a complete list of PCI devices, no need to rebuild it piece by piece by user's contribution, let's see if we can find a way to use the existing lists and tools in such a way to make your procedure easy to replicate to the final users. jaclaz