dencorso

If I were you, I'd RMA it instead of keeping defective hardware.

It's fixed, now! Too little sleep, probably, but I cannot even begin to fathom what happened!

OK. But have in mind that many things that make perfect sense just don't work... and, conversely, there's also a lot of things that make no sense at all, and yet work, including the Chewbacca Defense.

1) What do you mean by "scissor-key feel"? 2) Why don't you want to use a hub, but then put up with tandem converters happily? Connecting your keyboard through the converter to a USB hub, and your mouse to the same hub would still use just one USB port and should work even if you use a USB 1.1 hub (which is worth less than US$1)... see: a good keyboard cannot comunicate at more than 0.5 kiB/s and the best mouse won't do more than 10 kiB/s (probably less than half that), while USB 1.1 allows for 1.5 MiB/s, so it's way good enough for this use.

Welcome to MSFN, seam! Because they are different OSes, having different architecture and using different drivers. So, its not surprising... on the contrary, it is to be expected. And it's not at all dependent on what kind of device one is using, of course. See, below, the results for a Gigabyte i-Ram (Hardware DDR RAM Disk), using CrystalDiskMark 2.2: GB i-RAM 1.5GiB (Win 98 SE) -------------------------------------------------- Sequential Read * : 122.069 MB/s Sequential Write * : 120.388 MB/s Random Read 512KB : 115.096 MB/s Random Write 512KB : 119.392 MB/s Random Read 4KB : 44.253 MB/s Random Write 4KB : 41.041 MB/s *Test Size : 100 MB GB i-RAM 1.5GiB (Win XP SP3) -------------------------------------------------- Sequential Read * : 132.878 MB/s Sequential Write * : 126.182 MB/s Random Read 512KB : 132.886 MB/s Random Write 512KB : 125.808 MB/s Random Read 4KB : 58.625 MB/s Random Write 4KB : 51.699 MB/s *Test Size : 100 MB I don't think caching has much influence on those results... However, for the record, I've disabled write-behind caching on all drives, the GB i-RAM included, so (up to the point each OS allows one to disable caching), my tests were done without caching. And, to my eyes, the results for both drives are not so different to justify postulating different caching as the reason for the difference.

Awesome, cannie! But I do have a question... Grub? Does Win 7 install grub? Or did you forget to add grub to the list of needed tools?

Sure! It is War Machine, all right.

Well... considering your present solution for video display I guess you might as well fasten an old armchair to the ceiling... and use salvaged 1945 fighter-plane seat-belts to keep you sitting upside-down on it! Now, seriously, forget about any manufacturer's drivers and go straight to PassingBy's NUSB for Win 98FE. You'll find it here. Also consider giving Shiva a four-port USB 2.0 PCI add-on card, preferably powered by a Via chipset. e-Bay is your friend!

Not quite. By doing this you'll be stripping the bitmap, but also another module that follows it, which starts at file offset 0x44006. The bitmap starts at 'BM' but ends at 0x44005, since the file size (the dword that follows "BM") is 0x1F836...

Even if you get the USB going, you'll still need drivers. NUSB 3.3 caters only for mass storage devices, and that a Wi-Fi dongle is not. So, the D-Link DWL-G122 USB dongle versions Ax, Bx or Cx, have drivers for Win 9x but version Dx has *not*. Hope you have one of the first three versions, not the Dx. See post #6, for more info on locating the version of it.

Where, exactly, does it put this journal, and which filename does it use, please? Of course, all your volumes are NTFS, right?

No. I did not, nor ever will. It may be unnecessary for RP9.6, but that doesn't make them obsolete. They are needed for the best possible functioning of 9x/ME, so you're misinterpreting Tihiy. Your reading of Tihiy's statement is sheer bad advice. What he said was, if you don't have them, it's still OK to add RP9.6. He did not, and wouldn't, tell anyone to actually remove them.

Hi, Brex! Welcome to MSFN! You'll sure find here help and support, so rest assured you've come to the right place.

Boot-Land is not heavy on GDI resources. MSFN is just a little more. Neither ever gave me any grief with RP 9.1.0 So I was surprised. I recieved the message when I actually was out of GDI resources. But I shouldn't actually *be* out of GDI resources at that point. So, maybe RP 9.6.0 does have a leak. But more probably the resources are just being cleaned properly but too slowly, since the system recovered both times, instead of crashing catastrophically.

Gape's uSP contains HotFixes, not only critical updates and brings your system to the most up-to-date state possible. I think it's a must, not an option. And yes, you can stick to uSP2, if you want. There's nothing to be careful about LLXX's patched ESDI_506.PDR. Her comment is from release time, many years ago. By now, it's time proven to be safe. So, after adding uSP, I'd add NUSB 3.3 [link] and, at least, the following unofficial updates: LLXX's patched ESDI_506.PDR v. 4.10.0.2225 (aka v. 4.10.0.2230) [link] or, better still, Maximus-Decim BHDD31e [link] , which includes it and EXPLORER.EXE v. 4.72.3612.1710 [link], and: This is my opinion, based on my experience.

Hi Tihiy! Just tested 9.6.0 RC... I removed 9.1 and rebooted, then installed 9.6 custom, without skins and 32-bit icon support, and rebooted. Got a 'The system is dangerously low in resources!', while browsing Boot-Land, folowed by immediate all round GDI breakdown, less than a minute after the system was up again. The system didn't crash, though, and after some 3 or 4 minutes all GDI related things (title bars, fonts and icons) were recovered to normalcy. I opened another IE6 window and came to MSFN, and the GDI resources went down again, but not as fas as before. Plus, the tray still flickers... Are you sure you updated the version for download linked from your post #388? Then again, the taskbar is locking OK. And the new <Ctrl>-<Alt>-<Del> dialog is great! But I still don't quite understand what does it mean by SYS resources... Maybe it should say "Global" instead of SYS, to avoid creating confusion.

I've had a nasty problem with .NET and my 98SE. For me it breaks the search feature, so I decided to remove it after installing. I succeeded, but had a real hard time at it, and don't reccomend the experience. As soon as I can I'll locate the post I did about it, way back when, and post a link to it here. I have .NET (v. 1.1, 2.0, 3.0 and 3.5, in parallel, as reccomended)on XP SP3, and there it works OK. But it's never been of much use for me, anyway. Here's it: Obnoxious find bug, related to NFR 1.1.

Here, take a good breath, sit back and delve into these two threads below, and you'll know what is it all about: The 16bit heaps expander thread and GDI Heap Extender.

Apearances can mislead. The one used by gora also tell you it's v. 1.41 and has the selfsame size, but its "PE Timestamp" is 04/15/2009 11:18:09 AM UTC and its internal strings show it supports Aspack 2.2, in addition to the other formats the version (PE Timestamp 11/25/2002 02:35:44 PM UTC) you used in the Universal Extractor 1.6 also supports. So it really is an update, despite initial appearances. By the same token, gora's unlzx has a PE Timestamp 12/15/2000 04:49:57 PM UTC, while the version Universal Extractor 1.6 has a PE Timestamp 08/02/2000 02:17:44 PM UTC... So it's more tenuous, but I bet it's really is an update, too.

Yes, but not an exact multiple of #cyls * 255 * 63... and this results in just 80 heads on the last cylinder, for all HDDs I've ever seen. Let me give an example: Here's a 80 GB Seagate Barracuda 7200.7 ST380011A, partitioned by the book, with the last head-challenged cylinder also turned to an unconventional partition (from which it was possible to boot DOS 7.10!). It has 78150586 KiB of total usable space ( = 74.53 GiB): Ranish Partition Manager Version 2.43 (beta) by Muthu Apr 09, 2002 HD 2 (129) 76,319M [ 9,729 cyls x 255 heads x 63 sects = 156,301,488 sects ] File Starting Ending Partition # Type Row System Type Cyl Head Sect Cyl Head Sect Size [KB] 0 MBR Master Boot Record 0 0 1 0 0 1 0 1 Unused 0 0 2 0 0 63 31 2 *Pri 1 FAT-32 (0B) 0 1 1 882 254 63 7,092,666 3 Pri 3 Extended LBA (0F) 883 0 1 9,728 254 63 71,055,495 4 +-Log Win FAT-32 LBA (0C) 883 1 1 2,139 254 63 10,096,821 5 +-Ext Auxiliary (05) 2,140 0 1 3,384 254 63 10,000,462 6 +-Log Win FAT-32 LBA (0C) 2,140 1 1 3,384 254 63 10,000,431 7 +-Ext Auxiliary (05) 3,385 0 1 5,873 254 63 19,992,892 8 +-Log Win FAT-32 LBA (0C) 3,385 1 1 5,873 254 63 19,992,861 9 +-Ext Auxiliary (05) 5,874 0 1 9,728 254 63 30,965,287 10 +-Log Win FAT-32 LBA (0C) 5,874 1 1 9,728 254 63 30,965,256 11 Pri 2 FAT-16 LBA (0E) 9,729 0 1 9,729 80 63 2,551 And here's the same 80 GB Seagate Barracuda 7200.7 ST380011A, partitioned by using head 81... It has 78150617 KiB of total usable space (still = 74.53 GiB ...), that means 31 KiB recovered from space otherwise used in partitioning structures (I know it's not a lot, but, not so long ago, it meant 22 "1.44 MB" floppies! ): Ranish Partition Manager Version 2.43 (beta) by Muthu Apr 09, 2002 HD 2 (129) 76,319M [ 9,729 cyls x 255 heads x 63 sects = 156,301,488 sects ] File Starting Ending Partition # Type Row System Type Cyl Head Sect Cyl Head Sect Size [KB] 0 MBR Master Boot Record 0 0 1 0 0 1 0 1 Unused 0 0 2 0 0 63 31 2 *Pri 1 Win FAT-32 LBA (0C) 0 1 1 1,256 80 63 10,091,340 3 Pri 2 Extended LBA (0F) 1,256 81 1 9,729 80 63 68,059,372 4 +-Log Win FAT-32 LBA (0C) 1,256 82 1 3,757 80 63 20,089,251 5 +-Ext Auxiliary (05) 3,757 81 1 5,013 80 63 10,088,820 6 +-Log Win FAT-32 LBA (0C) 3,757 82 1 5,013 80 63 10,088,788 7 +-Ext Auxiliary (05) 5,013 81 1 9,729 80 63 37,881,270 8 +-Log Win FAT-32 LBA (0C) 5,013 82 1 9,729 80 63 37,881,238 The above are the output of RPM's <part -d 2 -p> command, somewhat edited for more clarity (and the colors, the result of the code tag's fancy). Of course, since it's really a full LBA setup, this geometry (retranslated from LBA to CHS by RPM) is ficticious in any case, corresponding to the real internal geometry of the HDD in no obvious way, but it illustrates nicely my point. All this was done with RPM 2.43, which is not very popular, but is my favorite (and, if I'm not mistaken, also has the same problems as 2.44 with its settings sticking in SATA).

While I really don't believe in "Security through Obscurity", this is a controverse subject, with no real consensual answers... You may want to read Surviving Without a Virus Scanner and Infection with tenga.a virus, for a start. BTW, what I do, with a setup similar to yours, is having AVG 9 (the paid-for version) in the Win XP partition, and have it scan every partition from there, whenever I boot to XP, which is becoming more and more frequent. I do also have a tweaked AVG 7.5 (still up to date) doing its job on the 9x/ME partition, but that won't last much longer...

Did you use a SATA HDD? I've seen the problem you mention for 2.44 only with SATA HDDs... And yes, 2.40 likes Head 81, as it helps use the drive more fully and works OK with LBA. But you can always reset by hand any of the values it offers by any other you want. RPM is powerful and very dangerous for the casual user... Thanks!

RLoew, do test RPM 2.44, too, please. Despite the caveats, it's the most used version, in my experience, and it's perfectly reliable, AFAIK. Older versions than 2.40 still float around the net, and they do use "05" as the default. One scenario is the following, for any version, if I'm not mistaken: it will create nonstandard extended partitions if you ask it to create an extended partition early in the disk (it'll default to "05"), and then define a logical partition, quick format it, and select it again, press <insert> to get the format menu and select FAT LBA... It'll create the "0C" logical partittion but won't correct the type of the container extended partition to "0F". I know this is somewhat contrived, however, but... Also, could you please elaborate on the above quote, please? Thanks, Joe! So it actually is as I thought it was.

42

And we're glad to have you here! Welcome to MSFN!