osRe

Anyone got Process Explorer >9.xx to work on plain 98SE? I tried 10.20, 11.00, 11.11, 11.13, 11.21, 11.33, maybe some others, none work. The initial post in "Last Versions of Software for Windows 98SE" thread says v11.11 is the latest to work. The changelog mentions for v11.13: "Fixes compatibility with Windows 9x and NT4". The CHM file for various v11.xx says 9x is supported. Yet, no go. Some newer 11.xx do nothing, some show the EULA dialog and afterwards a tray icon + taskbar button and nothing further happens, or the computer gets stuck(/ish).

Anyone having trouble running Audacity with an SBLive? Both version 2 and 1.3.14 (ANSI) crash on startup in EMU10K1.VXD.

I just found out "dir /s /a" will not recurse hidden subdirectories. I don't know how I missed it until now. Maybe because hidden dirs just aren't very common. I looked for a solution and found the obscurely named DOS FIX utility, that patches COMMAND.COM to fix it. It's appears to be a generic patcher, and works for Win98SE even though it's not mentioned in the docs. It changes the flags passed to DOS's FindFirst and FirstNext functions. For Win98SE the patched bytes are at offsets 0xA2B2 and 0xA2BE. In both cases the byte 0x10 (directories) is changed to 0x16 (directories, system, hidden).

Thanks for all the info, people. Good thread.

Or the chipset.

rloew, any idea if there's a problem when the extended partition is larger than the clamped disk size (whether in DOS, Win98 or WinXP), or when an NTFS partition crosses it? It could be interesting keeping an NTFS partition in the area hidden by HPA, for rare special uses. The drive I clamped the size on loaded fine in XP, with the NTFS partition that spans beyond the clamped drive size just being inaccessible. XP also wanted to chkdsk it on startup. The lower partitions seemed accessible as usual. DOS loadable DDOs would be interesting for experimentation sometime. I might be worried about what happens write-wise before Win98 loads the native driver, but what could happen before loading something in AUTOEXEC or CONFIG? It also seems practically 100% controllable. Oh, I see. I believe it's safe. Why wouldn't it be? It's both within the BIOS detected size and the Win98 supported size. In that case, I wonder how common it is. I see it on two ASUS mobos, one of them 48-bit capable. Yes, I already did. Next one to clamp a drive in this thread should try DCO, to see if there's any difference.

jaclaz, I want more than 8GB, of course. And I don't like the idea of DDO. Even more so when I don't know what it does exactly. And being MBR based. The HPA/DCO clamp allows me to use 137GB safely. The other option one could consider is loading an AUTOEXEC.BAT/CONFIG.SYS utility to disallow writes to certain partitions. In DOS I used to use a small COM utility that made HDDs write protected. But that may've been limited to certain int 21h or int 13h functions. But all of the above assumes writing at (BIOS_size < n < 137GB) leads to corruption. Maybe it is not necessarily so? Even a failure with an error (and no write) could be a useable for the limited cases Windows might attempt to write there during early boot. As for relying on CHS limit-aligned partitions, that seems unsafe to me. It's difficult to tell what all the involved pieces of code do, and even slightly off is just as bad. Regarding the max sectors for 137GB afflicted BIOSes, looking at the behavior of two BIOSes, one based around Award 4.51, the other around a 48-bit capable Award 6.0, it seems it's not 2^28 but (2^20) * (2^8 - 1). submix, I don't think the 8GB detection is about the chipset/controller, but about the BIOS. I also saw 8GB (with HPA set to 2^28 or a little below) on a different chipset with a 48-bit BIOS. I guess they fallback to CHS. Regarding P2B BIOSes, I'm using the latest ("beta") since it was needed in the past for something or another. There are no different BIOSes for different hardware revisions, but there are for different mobo variants (P2B-F, etc.).

That's how I did it initially (Win98 partition within BIOS size, extra FAT partitions all within <137GB, NTFS in the end), but what rleow brought up makes sense. Some FAT partitions are outside the the BIOS detected 8GB size. Some things may try to write there before Windows loads its native drivers, particularly if there's software installed there. That might lead to corruption. My vague understanding is that this isn't a problem with XP which loads its native drivers early.It would be interesting to check what happens when writing above BIOS size but below 137GB, but that's for another time, and the findings may not be generic.

jaclaz: Oops. I only read the part about 137GB. I wonder if WD's tool is effective for larger capacities, but in a way HDAT2 seems like a nicer tool. submix: Thanks for all the help. I know it's the 48-bit vs 28-bit issue. I looked for jumper solutions too, but only found mention of a 32GB clamp for WD. I'm not fond of the idea of DDO. MBR dependent, possible translation issues later on, etc. But for size clamping, setting the HPA with HDAT2 did the trick. There's no risk as far as I can tell. HPA and DCO are tweaked with standard ATA commands, and it's reversible. I just set it multiple times on two computers to see how different values are detected by both BIOSes. Now, just for the sake of completeness, I'll do some high-LBA tests in plain DOS. My conclusion so far: for 28-bit BIOSes + Win98, HPA (possibly also DCO) clamping seems like the cleanest option if you don't mind the lost space.

Oh, didn't notice it was Win95 rather than Win98. But don't, for example, CreateEventA or GlobalUnlock exist also on Win95?

I think you might be trying to understand the plugin's idiosyncrasies more than anything about the software you check. Maybe ask the plugin author?

Thanks. I'm generally aware of the cause for various limits. But this page is old, so no mention of 137GB. What I do wonder about is whether the 137GB limit is 65536 x 16 x 255 or 65536 x 16 x 256? The current day AAJBs are probably different than a few years ago (the one I have is from 2006-7), but their "public" model number if the same. The exact details are probably indicated by the suffix (a few letters and numbers, I think 5 of them, e.g.: (WD1600AAJB-?????), but that isn't documented as far as I know. They just mention various limitations, but I don't think there's a WD tool to set it, but... That's what I thought about. I don't know if Seagate Tools will work for a WD, but HDAT2 should. I'll try it in a while. Any idea if it's better to limit through setting the HPA or DCO (assuming both will affect BIOS detection)?EDIT: Well, it seems to work so far, using HPA. The limit seems not to be 2^28, but 65536 * 16 * 255 (267,386,880 sectors). Anything above, and it's detected as 8GB again (I suppose using CHS instead of LBA?), and strangely also on a 48-bit capable BIOS. Another thing, I used the 28-bit version of SET MAX. The 48-bit seemed not to be detected correctly, but I didn't pay enough attention so it could just be that I set it to more than the 267M limit. I guess I'll use a slightly smaller number to be on the safe side for 1-off errors (then again, if a 1-off is multiplied... maybe safest would be to set to something common, like the equivalent of 120GB HDDs).

Maybe setting the HPA or DCO max address will be just as good?

submix8c, thanks for DDO link. I'm not comfortable with the idea of DDOs. Maybe if there were a generic one that could be loaded from AUTOEXEC.BAT or CONFIG.SYS, rather than MBR. But even then it's somewhat worrying. More specifics on the mobo and HDD: mobo rev 1.10. But the differences are likely in things CPU voltage support, etc., rather than anything pertinent here. HDD-wise, the only extra info there is is the non-documented suffix of the model (stuff like -00JJD0), which I could check if you're interested. 128GB/137GB is the BIOS limit. I used the external HDD. It's not used for booting, and it's on a controller card.But rloew brought up a good point. Some write actions can be done before Windows booting completes, and those might use BIOS functions. Even if the OS partition fits within the BIOS detected size, I actually do have an additional software partition that doesn't. If only the BIOS treated the HDD as 128GB, or even 10-20GB, that'd be enough, but 8GB is very borderline. Too bad there's no 128GB clamp jumper on the drive. I might solve the problem by doing more HDD rotations than I anticipated. :-/ For a boot drive?!

I don't know what that plugin lists as "not successfully loaded". A brief look suggests these functions are present in Win9x, so I don't know what it is.

The mobo is ASUS P2B, the HDD is a WD AAJB. But I don't want custom BIOSes or anything exotic, and I don't care about DOS as long as Win98 can boot the drive correctly. Beyond booting I'm already using something similar: a 500GB external drive with the initial ~128GB as FAT and the rest NTFS. I just don't know if booting might be affected by the BIOS misidentification.

Am I correct in assuming I can run a 160GB HDD with Win98 and no BIOS support (which detects it as 8GB) as long as just don't use areas >137GB? It's the BIOS part I'm not sure about. Does it matter for anything other than DOS? Is booting affected? The boot partition is 2GB, so it falls within the 8GB detected by the BIOS.

The forum stats box says: Online At Once Record: 23,998. Surely a bug of some sort?

Another data point. My registry size (base 10): SYSTEM.DAT 14.5MB USER.DAT 3.1MB

It depends on the controller. If you can't find a driver in the card manufacturer's site, try the site of the controller chip manufacturer; Silicon Image, VIA, etc.

Don't forget the users.

4K sectors are getting more and more difficult to avoid. And regardless of partitioning scheme, 4K sectors need attention, also in drives that expose it as 0.5K sectors. Regarding HDD sequential speed, speed is largely a factor of areal density (and rotation speed). HDD platters store more data now than before, so speed increases. For example, a test of some 500GB HDDs from 2010. In a synthetic test, all except WD Green are >100MB/sec (IOMeter synthetic tests later in the review show somewhat lower speeds): http://www.xbitlabs.com/articles/storage/display/500gb-hdd-roundup_5.html#sect0 Real life test shows similar results on reads: http://www.xbitlabs.com/articles/storage/display/500gb-hdd-roundup_13.html#sect0 SSDs have pretty much maxed the interface for a while now, with >500MB/sec speeds.

IDE drives are more expensive, so I'd go with SATA, or SATA+IDE as long as SATA support is fine (chipset, drivers, etc.). If you want to use the mobo IDE ports, you can get SATA-to-IDE adapters that mount directly on the back of the drive, or an IDE-to-2 SATA adapter cards that plug into a mobo port (better in theory, but seems messier physically). Boot delay-wise, I suspect, but don't know for sure, that you could erase the flash to disable the BIOS and associated delay. I haven't encountered SATA 1.5/3.0 issues on my 1.5 card, but only tried it with a WD Blue and a Samsung F1. One possible thing to mind with newer drives, though, is 4K sectors. I'm not sure what implications this may have on Win98. Maybe just aligning the partitions will be enough. And that Wikipedia claim on needing OS-specific support depending on drive transfer speed sounds dubious. I have a SiI3512-based card that I use for eSATA on a Win98 computer, and a in another computer a SATA-to-IDE adapter based on some JMicron chip. I don't remember which one. BTW, there are various past discussions on SATA controllers in the forum. TmEE: All modern HDDs can sustain >100MB/sec at low LBAs. And I think it'd actually matter less with multiple simultaneous disk operations, because then you'd be seriously bottlenecked by head movement and rotational latency.

Maybe check if the certificates are indeed saved (that's what I understand this addon should do?). BTW, a possibly better browser for Win9x is Opera 10.xx.

I chose "Never", but that depends on how you define "use". I did have it installed for some time, and did occasionally use it, but it was never used as an OS per se. I used it more like you use a software, running it when needed for specific things. DOS was my main OS, which also continued as a dual boot option with Win95, and maybe even Win98 for a while.