dencorso

If you want it on FAT-32, I'd say: (i) start with a single HDD on the machine. Partition and install Win 7 with the default installer, on NTFS. (ii) add a second HDD, create on it a FAT-32 partition of the same size of the NTFS installation and clone it to the FAT-32 partition, on a file-by-file basis. (iii) remove the HDD containing the NTFS installation and (if IDE) make the FAT-32 installation the master HDD. (iv) use the "bootsect /nt60 C:" to restore it's bootability (see: KB933168). This is roughly what Dietmar did to create Vista on FAT-32. It should work for Win 7 too. You can manipulate all other partitions and the MBR by the old methods. You just need the special nt60 PBR on the Win 7 installation partition.

jaclaz, The Finder, you do rock! I confirm FolderSort works flawlessly in Win XP SP3. And it's freeware! Wonderful! Great find!

I disagree: directory sorting messes just with the directory structure, while a defragger will tackle the physical location of the files also, which takes much more time. And even if one may be able to configure some deffragger to just to do a directory sorting, it seems to me akin to using an Exocet to kill a common flea.

Glad you're here. Welcome!

At long last, I've just finished updating post # 166.

Since no small amount of modding will get you to fool Abe Fettig's Javascript Method of detecting IE6 and older IE versions, I see no point of doing anything beyond the reg spoof, which works quite fine for most sites. Unless you're in for a serious rewritting of IE6... but, then again, are you?

Way back when, there was DS.EXE (Directory Sort, part of Norton Utilities for DOS, hence not free), that did exactly what you want. However, even Version 8, the last one, did work only with classical DOS directories, i. e., it doesn't understand LFNs (the Long File Names) added shortly after MS-DOS 6.22, so I think it's not an option anymore, although I haven't tested it to see what it does to a directory containing LFNs (but I suspect the result probably isn't pretty...). On the other hand, I've never found a newer program, LFN aware, created to fill the gap left by DE.EXE (either free or not free), and I suspect none exist. If you ever find one such program, be sure to post about it, please. Later edit: on searching again the web, I just found the shareware LFNSORT, by Duncan Murdoch. However, it was written for Win 95, so there's no telling how well it works (if at all) on the NT-Family OSes (2k, XP, Vista and Win7) with FAT (12, 16 or 32), but it may be worth of a try (of course it doesn't work with NTFS, since it knows nothing about it). Duncan Murdoch seems to have discontinued it, since it's not listed anymore in his programs page, but the downloadable file remains available for those who know the link I posted above. For more info, please do contact Duncan Murdoch (contact info is given on his homepage). Good luck! And please keep us posted.

Perhaps Anton Bassov's reverse-dummydisk (to make "removable" a "fixed" drive), will do the trick, see: "How to boot/install from USB key? - the historical thread", post #422. But AFAIK it's restricted to USB devices. Maybe you can convince Anton Bassov to generalise the driver for you... I'm sure jaclaz or ilko_t can help you much more than I can, on this matter, though.

You're quite right! In userInfoModule.js it really is! It's the "(typeof document.body.style.maxHeight === "undefined")" But no, it doesn't rely on "User Agent", nor on "Version Vector", and, in fact, it doesn't read the registry at all: it's Abe Fettig's Javascript Method of detecting IE6 and older IE versions, and it detects a feature not present in any version before IE7, so it relies on an intrinsic difference between IE7+ and IE6- ... I don't know how to spoof that, and I suspect it won't be easy to do it, if a method is ever found, sorry! Here's more info about it: Detecting IE7+ in JavaScript (Abe's blog) Detecting IE7+ in JavaScript (ajaxian) Fix Min/Max-Width for Browsers Without Native Support Suggestions on how to spoof this method are most welcome! P.S.: It's not clear to me what the "mamabar" bit does, however.

You may delete both also. If the HID compliant device turns out to be something still attached, it'll be redetected on reboot. It probably is a drawing tablet, joystick, mouse or keyboard, or even a local bluetooth access-point...

Sure. You may delete these 4 entries. It's safe.

Most true. Norton Image is not an imaging program (it just saves a snapshot of vital system areas). The imaging program from Norton/Symantec is Ghost (and for most purposes the best version of it is 2003). Another main characteristic of a true image is that it's a time-frozen bit-by-bit replica of the original, and thus it *cannot* be acquired from within a live runing OS. To examplify using your system as a reference, Dave, you might acquire and image of the 98SE partition while running 2k, or an image of the 2k partition, while running 98SE. But to acquire a full disk image, you'd have to boot from a DOS diskette, because, in this case, both installed OSes would have to be inactive for the image acquisition to succeed. Or, in other words, while an OS is running it constantly makes changes to its own partition, and these changes would result in a flawed image being created, which would not correspond to the actual partition state at any time at all, because of being acquired while changes were actually being done to it. And since a realistic image acquisition procedure might take from 10 min to 1 h or more, a lot would have changed from the start till the end of the image acquisition.

NO. NO need WHATEVER of being same brand, model or size. True enough. You're right, yet I'm right too. This is just a problem of semantics... The only way you can have a true clone is by using the same brand, model and size. But you can, of course, do as you say and arrive at a near-enough clone, which will be indistinguishable from the true clone, for almost all (if not all) purposes, at least in real-word scenarios... and no, I just cannot come right away, from the top-of-my-head, with an example of a case in which they would not be indistinguishable, but I firmly believe there may be some such examples, if one really cares to search for them.

jaclaz is right, Dave, there are as many solutions for this as the proverbial stars on the night sky, so any attempt at being exhaustive is futile. So I'll tell you something about those I use (but even of those there are many variants and I'll be focusing in the ones I use, too). An Image may be thought of as an exact, sector by sector copy of a whole disk or of a single partition, regardless of any higher-level organization, and of these we have: A Forensic-quality Disk Image contains all sectors in the disk, and permits the re-creation of a truly identical image, including all the otherwise irrelevant unaccessible sectors created by partitioning (such as the last 62 sectors in the MBR track of a common HDD and all sectors in any leftover unpartitioned space at the end of the disk). Such an image requires , to be deployed on a diferent HDD than the one it was made from, that the second HDD be of the same brand, model and size, but will result in a truly exact copy, that is a true clone. A Common Disk Image may be thought as similar to the Forensic-quality one, but omitting those otherwise irrelevant secftors, and, maybe the free sectors also. When deployed it'll result in something near a true clone, but not identical. Depending on what was considered irrelevant at image acquisition time, it may result in an almost perfect copy of a disk, yet be imperfect enough to render it unbootable, or even completely unusable, in the worst case. An Exact Partition Image (my favorite) would be like the Forensic-quality Disk Image, but restricted to a single partition. A Common Partition Image would be like the Common Disk Image, but restricted to a single partition. To create such images one may use a "dumb" imaging program or an adaptive imaging program. The "dumb" one will acquire the image as-is and deploy it "as-is". The adaptive one can do much more interesting tricks, such as deploying a partition image to a bigger partitition (thus serving to grow a partition in a safe way), or even deploying a partition image to a smaller partition, provided it's big enough to contain all but the free sectors in the image (thus serving, in a limited way, to shrink a partition safely). The same kind of tricks can also be played with full disk images. The best imaging programs, besides being adaptive, are also capable of compressing the images they create, so that one has no need of compressing them with another program for storage purposes, and also provide one with an image browser, so that one can extract individual files from the (compressed or not) image without having to deploy it somewhere just to do so. That much having been said, the bottom-line is: in principle, imaging is based in sectors, and should be independent of the underlying OS. A Backup may be thought of as an exact, file by file copy of a whole disk or of a single partition, so it involves interpretation of the existing structure by the OS, and of these we have: A Full Backup An Incremental Backup Taking the partition backup as the example, the full backup would be a file-by-file copy of all the contents of a partition to another empty partition or a directory (a somewhat worse alternative), while the incremental backup would be to add or update just the new and/or modified files to an already existing backup. So one always starts doing a full backup, but then can switch to incremental backups, which are much faster (at least when based solely on date-stamps and file sizes). The de-facto standard program to do backups is the freeware xxcopy, IMHO, and if we're thinking Win 9x/ME, one should use XXCOPY FREEWARE v.2.96.5 - http://www.xxcopy.com/download/xxfw2965.zip, which is the last version that works in 9x/ME. I tend to favor using images for the system partitions (on a weekly to fortnightly basis) and incremental backing-up for data partitions, on a daily basis, because data partitions change much faster than system partitions. YMMV, though.

Congratulations, Dave! This issue was a hard one to go down, especially so because it was threefold: the sound issue, the Integral pendrive issue (which, in fact, we caused, while troubleshooting the other two, then solved) and the main NUSB 3.3 issue... and thus it became a real brain surgery. The fact that it has been solved shows that, with persistence, careful experimentation and never-ending patience (and a clean, plain-vanilla alternate installation to experiment on, too), a full reinstall from scratch can always be avoided. But it also shows how labor-intensive it is to recover without an up-to-date library of backups. And, to create that, an imaging program is a must. Create a full system image once a month, and also always before major installs, and you can always fall back to your previous system state in 30 min or less. So your 1st priority, now, must be to set-up an imaging routine. All the rest can wait. Below are two quotes relevant to this matter. Whatever program you select to use, be sure that it's capable of creating images of individual partitions, so that you'll be able to backup individually each of your OSes, on a as-needed basis.

True. FAT32 is very flexible and has wide limits. But going above 26 million clusters limits its usability because most of the available programs to give it maintenance weren't written to support so many clusters, as discussed elsewhere:

IMHO, nothing. I also cannot say that either .NET Framework 1.1 or 2.0 do slow the system. It just lies there taking disk and registry space. But: (i) To remove *completely* either or both .NET Framework versions is a real PITA. (ii) In my experience .NET Framework introduces a search bug. Read all about it here: Obnoxious find bug, related to NFR 1.1. Since I multiboot Win 98SE with XPSP3 and true DOS 7.1, I've decided to let my 98SE installation .NETless. It took me some two days of experimenting and research to really rid the OS from it. And now, in the rare occasions I need to run something that requires .NET, I do that from XP, where I have v. 1.1, 2.0, 3.0 and 3.5 installed. But I've needed it no more than twice or three times, since 2007.

There is no substance to that idea at all. Win 9x can and will use all the memory available to it, although it rarely uses more memory than about 800 GiB, in my experience (but open various big .BMPs at the same time and it will use more and more). You don't need to believe me, just download and run Japheth's excellent VWin32, and see it for yourself. Urban legends are hard to kill.

@Click Beetle DX: While I cannot test it myself, I have a suggestion: Fallback to the original versions of the files listed below: TAPI.DLL 4.10.0.1998 TAPI16.EXE 4.10.0.1998 TAPI32.DLL 4.10.0.2222 TAPIINI.EXE 4.10.0.1998 TAPISRV.EXE 4.10.0.2222 TAPIUI.DLL 4.10.0.1998 TAPIUPR.EXE 4.10.0.1998 TELEPHON.CPL 4.10.0.1998 Notice that not all of them are substituted by 98SE2ME, so check their versions, and those that already match the version number to the right of each name don't need to be replaced. Those that don't, you should rename and add back the original one, from Win 98SE CD. After testing, please do report whether this solves your issue.

For these infs only, if there is a pnf of the same name, disable them too. Then look inside them for references to .vxds, .pdrs or .mpds, which, if found, will be located in system/iosubsys, or system and disable them too. Then return the system.ini you saved after recognizing the HP flash drive but before the first detection of the card reader. Then reboot into win98 and try once again detecting the card-reader.Also: get the fantastic APSoft VxDView, and install it into both your main and your clean win98 installations and compare the list of vxds and pdrs that are loaded and running in each of the installations, in real time. And compare the contents of system/iosubsys in both installations, too. There *is* a difference: we must insist until we find it.

Dave, whatever is wrong must be referenced in an .inf, AFAIK. So I think the first step must be to compare C:\WIN-98\INF in both installations, find out which .infs exist in your main installation that don't exist in the clean one, and, among these, which refer to USB devices. These latter must then be decativated by renaming, and the detection of the card reader repeated, in order for us to pinpoint the offending .inf(s). If this procedure doesn't lead us anywhere, then I'd try importing the keys you've saved. There is something interfering with the correct detection of multi-dispositive devices in your main system that must be corrected, to avoid problems with further devices in the future.

It's a good idea. Go for it! Let's see what happens.

NUSB 3.3 mounts both partitions of my Iomega 500GB HDD without a hitch, Dave. Fall back to the registry saved just before inserting the card reader for the first time and, before anything else, apply IOSYS98 and KB240075 UHCD.SYS hotfix (never minde that it's said to be for AMD and/or VIA only) and let's see whether this solves your problem. If that's not enough, we should compare the drivers in both our systems, to see which are different, and then try those. But I doubt the problem lies in msgsrv32.exe, since I too use v. 4.10.0.2222 (the one from ME doesn't work in 98SE, AFAIK). Meanwhile, find out what ChipGenius, under 2k, has to say about the controller of the card reader. Later edit: Dave, give a look at this post also (read #22 to #30, please). Observe there's no need to remove and reinstall NUSB, you may simply create a modified usbstor.inf and substitute it for the original one in true DOS or from 2k.

Thanks for the screenshot, Dave. Yes. I think you are ready to go ahead and install NUSB 3.3, now. After installation and reboot, I suggest you give it the HP 2GB flash drive to recognize, as the first test, then proceed to the card reader, and let the mode 7 Integral ICE USB 2.0 Flash Drive as the last one to be tested, because it's peculiar, as we all now know. Good luck!

HI, Dave! OK, but first do create a *full* backup of your 98SE partition, plus a mini-backup containing just MSDOS.SYS, AUTOEXEC.BAT, CONFIG.SYS, WIN.INI, CONTROL.INI, SYSTEM.INI,USER.DAT and SYSTEM.DAT. You're right, NUSB is only interested in mass storage devices, so those devices you mentioned can be safely let remain in the system. But, then again, NUSB 3.3 installs a generic USB 2.0 stack, so that you ought to remove any Enhanced Host Controller present before installing. Please post a screenshot of your device manager with the USB controllers hive expanded, so I can advise you whether there is anything more to be removed before going on and installing NUSB 3.3, OK?