dencorso

How did you block it exactly, Queue? That should be described in detail, since it can help most users here.

Hi, brown29! Welcome to MSFN!

Quite true. That's why I think real-time scanners are a must, and will keep my AVG 7.5 going even after updating the definitions becomes impossible (which may happen anytime, now). And AVG 9 for XP SP3.

Since I know you have it, I strongly recommend GDISK (under DOS) for this task. It's not fast, but it is thorough.

Here's some noteworthy info from the selfsame links Multibooter posted on the 1st post. From the viruslist entry "Virus.Win32.Tenga.a": From the f-secure docs on Tenga.A: IMO, by comparing an uninfected file with the same file after infection, using BeyondCompare Hex comparison without alignment, one ought to find the exact offset in the DOS stub where it places the ASCII "V", and if that's a constant offset, use it to quickly determine which files are infected.

If you have plain Win98SE installed and have not installed any of the various updates that are available here or any of the packages from MDGx's, I think you can safely assume that you have VCACHE.VXD version 4.10.2222, as this is the version included in the 98SE CAB's. Well, that's really a difficult question, which usual answer is you won't easily be able to, because, even if you manage to decompress VMM32.VxD and get the separate files it's made of (easy with VxDLib.EXE), you'll find out that the version part of the component VxDs is removed by windows, during VMM32.VxD compilation, shortly after the initial installation. However, windows never again recompiles VMM32.VxD, unless you explicitly cause it to, deliberately, and in a rather elaborate way. It cannot be done unwittingly, so, unless you know you recompiled it, it wasn't done, and both VMM.VxD and VCache.VxD, if inside it, *must be* v. 4.10.0.2222, provided your OS is Win 98SE. Now, as to whether they really are inside, that's easy: 98SE wouldn't even start in case they were not. They are both fundamental parts of the lowest level of Windows kernel. However again, when you install MS updates to VMM.VxD and VCache.VxD, since it doesn't recompile VMM32.VxD, it must have a way to override the files existing inside VMM32.VxD, and it sure does: it simply adds the updated VxDs to the C:\WINDOWS\SYSTEM\VMM32 folder, and any files in that folder, having the same name as any of those inside VMM32.VxD, are loaded in preference to their namesakes inside VMM32.VxD. So, you have just to check whether you have a VMM.VxD and/or VCache.VxD in the C:\WINDOWS\SYSTEM\VMM32 folder... if you do, those are the files used, and you can find their versions from their properties tab... if you don't, then it's safe to infer you're using the plain vanilla files from inside VMM32.VxD. If you have Win 98 FE they'll be v. 4.10.0.1998, for Win 98SE they'll be v. 4.10.0.2222 and for Win ME they'll be v. 4.90.0.3000. HTH

I've got two comments: [ot]The Sharkoon's Flexi-Drive S2S is a true hardware RAID, so it's bound to be fast, if used with the right SDHC cards... I had those SanDisk Extreme III SDHC 16GiB, which are the so called 30 MB/s edition, and that under real world conditions really attain sequential reads of just over 20 MB/s... Under RAID0 that would be 6x times faster, bordering on the limits of the SATA I connection you'd have to use for 98SE to be able to recognize it. Then again, the MTBF would be about 500,000 h, i. e.: 1/6 of that of the individual cards (>3,000,000 h, according to SanDisk).[/ot] You should consider adding SP3 to your XP. I'm using it since about one month after release, and it's very stable and trouble-free.

Please tell me more about the current capabilities of your SATA patch. I see it has evolved since I originally bought my copy of it (which, unfortunately, I still didn't test, since I've got to postpone finishing the assemblage of my ECS GeForce 6100M-M2 board based machine, due to various more pressing matters).

Although not always, I do prefer doing things the "non-Microsoft" way in many instances, so you're not really alone in this forum. For instance, I set up my dual-boot machine by installing XP after 98SE, and not the other way around (which is recommended by MS). Moreover, I use GRUB4DOS, initiated from real DOS to switch between the systems, which, BTW, are in the 1st primary partitions of separate HDDs, one booting directly to XP if set as the 1st boot device in BIOS, and the other booting to 98SE or GRUB4DOS (selected via CONFIG.SYS) if set as the 1st boot device in BIOS (which is my default). When GRUB4DOS is selected in this latter partition, it first switches hd0 with hd1 and, then, chainloads the boot sector of the XP partition, from which XP boots normally. This has the advantage that no file from 98SE is present or needed in the XP partition, and vice-versa. This is definitely one "non-Microsoft" way, and works very well. Moreover, the system which has booted is always in C: and the dormant one is in D:. All the other drive letters are the same, regardless of which OS has booted, because I set the drive letters of all other partitions or devices in XP to be the same as the one DOS/98SE assigns, using the static letter assignment facility that XP offers to do it (so this part is done in the MS way). All partitions are FAT-32, and are accessible from both OSes. And even if one of the HDDs suddenly dies, the other will still boot.

Sure. In several ways. If you have a XP machine handy, the Verbatim formatter may be the easiest one to use. See this thread. After you use this tool to create a single partittion and format it, just copy the Win9x folder to it, remount it in the laptop and, after booting from the floppy, go to the Win9x folder and run Setup.exe. That should be it.

[far away offtopic] Multibooter, since you have many SDHC cards, you might find interesting this SATA II SDHC RAID: Sharkoon's Flexi-Drive S2S [/far away offtopic]

You misunderstood me. I meant you'd be all set to actually install Win9x. Of course you'd have to creat at least one active partition, format and sys the disk before anything. But how did you intend to copy a folder onto an unpartitioned and unformatted HDD? It's simply not possible.

Sure. You don't even need to actually remove the HDD from inside the laptop, in case you manage to disconnect it from the laptop and have space enough to insert the PATA/SATA --> USB connector in it. Then just copy the Win9x folder from the Windows CD to your laptop HDD, reconnect it to the laptop and you're all set.

Rename both MAPI32.DLL and Mapisp32.exe in program files\common files\system\mapi\1033\95 to MAPI32.ANT and Mapisp32.ANT, to disable them. Let alone \windows\system\MAPI32.DLL. Reboot and see what happens. Whatever happens, in case they are needed, all you have to do is change back their extensions. And in case you do find they are needed, try restoring just the extension of Mapisp32.ANT first, for the \windows\system\MAPI32.DLL to be used...

I'm sorry to hear of your system's infection. And glad to see you were able to recover fast. I agree with most of the preventive measures you've just spelled out. I wish to add just two or three more measures to the list: I)Full disk dumb sector-by-sector current images of the current installation burnt to read-only optical media (I use multi DVD+R DL images, and intend to move on to Blu-Ray soon), not older than two or three months, six in the worst case. Or that plus monthly dumb sector-by-sector current images of every partition, where feasible. II)Up to date virus scanner on the XP partition, performing a daily scan of all the partitions (I use AVG 9). and, if possible III)A completely independent machine, with its installation backed up on optical media to use as a sandbox. (I still don't have one, but that's my next move).

Well, this refers to MAPI32.DLL instead, but at least explains what the MAPI is (sort of). Also give a look at KB173299... I think maybe you've got a version that's too new. In my machine I have MAPI32.DLL v. 4.0.410.59 and no MAPISP32.EXE at all. But I didn't install Outlook 97, because I use web-mailers, so I just have Outlook Express, updated with the Maximus-Decim packs.

Well, a total address space absolute limit of 4 GiB for 9x/ME makes sense to me. Of course, if a workaround is found, I'd like to be aware of it, so keep us posted about your research. BTW, if you want to revise and update the info for the RLoew(7) machine (or any others), do PM me. As it appears now on the list, the swap file ramdisk has less than 1 GiB allocated to it, but that, of course, is due to your letting Win98SE/ME see 3327 MiB, in the reported configuration. Moreover, I understand you have at least one machine dual-booting Win 95, now, and that would be an interesting addition to the list.

Well, thanks for the heads up. But I'm quite stisfied with the current settings I'm using, and don't intend to change them. I do find my 1.5 GiB ramdisk quite useful.

Now, jaclaz, that was really uncalled for. I know Italians are intense (from experience, as I'm from Italian stock), but I do think you could have said it more respectfully, even so. Let's please tone it down, OK?

I fear the only way to do it from a USB HDD would be without USB hotplug support, and in compatibility mode. And it'd be quite work-intensive to do it... But, then again, I don't see why you cannot install it as a dual-boot machine, perhaps even using a second HDD. That'll probably be less work-intensive and give you better results. Or else you also can use a VM to run 98SE.

I respectfully disagree. More info here: CALL.

Of course it does work with .EXEs and .COMs... I think MDGx meant to say "CALL only works from within batch files". And, in a sense, this is true... If you invoke a batch file directly from within a batch file, the second batch fails to return to the first one, as it ends, causing both to terminate, while if you invoke the second batch file by means of the CALL command, then the second batch, after it ends, returns to the first one, which resumes processing normally. This is the reason for which the CALL command was created, in the first place. On the other hand, invoking .EXEs and .COMs with CALL or without it have the exact same result.

I can confirm that. My machine has 3 GiB RAM. It is divided in a 1.5 GiB Non-XMS RAMDisk (RLoew's) and 1.5 GiB RAM visible to Win 98SE (using RLoew's RAM Limitation Patch). When I attempted to set the PageFile to 3822 MiB (at drive J:\) it resulted in Windows overriding my setting and creating a smaller variable-size swapfile at the default location (i. e. C:\WINDOWS). But it gladly accepts MaxPagingFileSize=1835008 (= 1792 MiB) and creates the swapfile at J:\, as directed. While I did not try to find the actual limit of the MaxPagingFileSize setting, it clearly is less than 3.7 GiB and more than 1.8 GiB.

No, it does *not*! But the BIOS of your machine may have it, and the Ranish Partition Manager depends on the BIOS to work. AFAIK, only RLoew's RFDISK and RFORMAT can work independent of BIOS, in DOS. Always double-check your results for hidden dependencies, in order not to spread misinformation. I have used RPM (v. 2.44 Beta) to sucessfully format and partition two different 500 GB HDDs on two different occasions, and it worked flawlessly in both cases. One of those HDDs (the IOMEGA) I still have with me and it remains in use (more details are in the quotation below).

Follow the links LoneCrusader gave you (I now put them in bold type in the quotation of his post). Enter the User Agent String LoneCrusader provided you, which is now bold red in the previous quotation. It should just work. HTH