awkduck

I'm guessing you have over 512Mb/1Gb of ram? Rloew is no longer with us, but he created a memory patch. You could revert your SYSTEM.* files, and try the patch. Your runtime error could be the audio driver. Someone else was getting a similar error. If it is the audio driver, you could use USB audio.

In general/normal use case scenarios, I' have to completely agree with you. Grub2 seems limited, in some important ways. At least in ways that matter to me. However, time and time again, I run into odd machines that will not work "completely" with Syslinux or Grub4dos. USB booting (stuck at USB1.1 speeds or no USB boot at all), strange hardware initializing timings, and legacy USB mouse/keyboard not properly releasing. I've had one machine that would not boot from USB using Grub4dos, unless I first initialized Grub2's USB modules. This must have removed the bios issue preventing Grub4dos from working. A different machine worked fine, without the Grub2 USB modules; but would not work if I had the Grub2 USB modules loaded. You can also edit MSRs with Grub2. But as I've said, these are things you would "typically" not be dealing with.

I don't know if you are still working on this, but more information might help. Maybe Damnation's input already helped? What AGP Bios options are available? What VIA chipset is this? Does this machine already have an integrated video device? I've mostly worked with laptops and thinclients, these days. My accelerated video knowledge, with Windows, is on the decline. Pairing your AGP card info, with your VIA AGP chipset info, may help provide some insight. Is this a configuration that already works, with a different installed O.S.? Have you tried older versions of Catalyst (if your device is supported by them)?

Yeah, sometimes the machine just doesn't want to be your friend. After reading the indecent description, I wondered if the "so I boot into DOS, fdisk, delete primary dos partition" was done from the hard disk dos, or Cdrom/Floppy/USB. Not that it would probably made a difference; I'm just trying to pick at something. I don't recall ever using the installed FDISK, to erase itself. 173a might have been using portable boot media, as I always have.

I've noticed the following, in the ATI SMBUS inf file: Does Win98 need this? Or is it irrelevant?

One of the CD ISOs, that works, was made with WinOnCD. Still UCS Level 1 and no Rock Ridge.

genisoimage -J -ucs-level 1 -o test.iso /iso_files This ISO failed to function.

I noticed "Joliet UCS Level-1" on working ISOs. No Rock Ridge . I'll look into creating something.

Here are four ISOs. All failed, but work when copied. All are CD images. FreeDos Live. FreeDos Bonus. ReactOS Live. Aros Live.

I have gotten a CD ISO to work, that didn't before. I'm guessing that the reason it did not work, previously, was because of errors already tampering with the system. EDIT:{Or, I made an assumption.} But it still did not work, from the foreign partition. I had to copy it, which worked without corruption. The still existing copying issue, with larger files, may be related to Rloew's File64. I can't really test it, when his API is disables. Maybe foreign partition to/from FTP. But File64 is not causing the issue with some ISOs working/not working , from foreign partitions. This still remains, with File64 disabled; both CD and DVD images. EDIT:{I guess it has been tested, since the still working DVD ISOs copied fine. That "potentially" clears it up a bit. Now it is just an issue with why some do/don't work, from the foreign partition. If File64 really was the cause, of file copy corruption, then if points back to some ISO specification difference. I'll try to test ISOs, from opensource projects. Likely most will not work, and serve as examples. If I can't find a certain type, then I'll create one, and upload it somewhere. What will be harder, is making/finding one that works. I can't share the ISOs that work; especially here. I don't have the tools that made the original CD/DVD. I do have some of the tools that cloned them. Knowing how to make working ones, might end up being useful. If anyone has D-tool/VirtualCloneDrive, Paragon's NTFS PNTFS.VXD (Thank's SweetLow), and a USB NTFS partition, this could be tested. If others do not have the same problem, then it might even have to do with my NTFS partition's attributes.

You are right. It is PNTFS.VXD.

Eventually, I'll probably try them both. I am using BIO95DRV.VXD. It isn't important that I have access to ISOs, while the foreign formats are active. But, different circumstances are foreseeable. I mainly wanted to point it out, in case someone has a similar issue. Then a probably culprit would be known. I think we are both in agreement about this. I only differ, from your view, a little. I can not state is as fact, yet. Keep in mind, all of these ISO work "normally", on this machine/OS. So there is nothing wrong with them. While the foreign partitions are active, the issue arises; at no "actual" fault due to any ISO specification/format. At a glance, the difference has been mentioned. It may be that, at one time, there was once a specification difference. Perhaps not even an official one. But, specification difference may have nothing to do with. When the foreign partitions are active, I can also not copy these files; they do not copy correctly. This is what, in my opinion, dismisses the "20" issue; since copying the files has nothing to do with ISO formats. The stunning part, is that the issue persists when the foreign partitions are not involve. Just being active on the system is enough. I should examine what does copy over, and compare that to the original. It is also interesting, with the foreign partitions active, that the other ISOs copy and function fine. This would mean there is something about those files. ISO format may be, inadvertently, playing a part. I initially thought is was partition alignment, and that may still be involved. All of my considerations may be too narrow. Something else could be causing the issue; and BIO95DRV.VXD is only partially involved. I also considered hardware disk issues, but all ISO files otherwise work fine. It is also strange, that the issue is only with ISO files. I thought it might be a large file issue. But, one of the working ISOs is over 4Gb. All of this is really back burner for me. What I wanted the files for, is more important to me. There is an innate desire to flesh it all out. But for now, under my own time demands, I just copied the ISO content to folders.

The Volume Label is at "8028" just below the Volume descriptor. -this is not char count accurate, due to font spacing- ...........CD001..Win3 2 SUMVOLLAB ...... ...V!..!V............. ...................... ...................... ............".(......( ........{............. ..<- from here (80BE) to (823D) is "20" -> Vendor Name <- "20" till (832C) Just as an example.

"20" as a space in a string, is okay. That did not prevent loading. It was empty space using "20" or "20,00". Data gap, if you will. Normally found right after offset 8000. Large sections of "20", and sometimes additionally "20,00", around and after the Volume Label. The use of "20" and "20,00" may be irrelevant. It may be related to some format/specification, that just so happened to allow for that. Perhaps just certain ISO/Burner software. It may be possible that the "20" and "20,00" could be fine; but as a coincidence, the only images that worked, didn't have them. I'm guessing I could modify a working ISO, filling some empty chunk with "20"s, and it would still work. Some Vendor strings, of non-woking ISOs, "GEAR CD DVD RECORDIG" and " ULTRAISO". A working one is "Smart Storage, Inc". The "Smart Storage, Inc" ISOs have a much cleaner layout.

This is just a kinda note, in case someone else runs into it. I have NTFS support (Paragon), on Win98. This system has no internal drives, with NTFS. USB drives with NTFS and EXT2/3 are connected and used. When a USB drive "having NTFS/EXT*" is plugged in and active, certain ISO files cannot be used. This is tested with D-Tools and VirtualCloneDrive. I cannot even copy these ISO files. For example, from a network FTP to my FAT32 drive. These ISO files do not copy correctly. Once the NTFS filesystem "or other foreign type" is inactive, everything is back to normal. I took me awhile to figure out the culprit, because the files did not have to be on the foreign filesystem. It only mattered that the file system was active. Some ISO files did work. It did not matter if it was a CD or DVD image; nor the Rock Ridge, Joliet, or UDF type. It had something to do with how empty space was written. In hex, if the empty space was written with "20" or "20,00", the image would not work. If the image used only "00" for empty spaces, it would work; even if stored on the foreign filesystem. I don't know much about ISO structure. There is probably some specification difference. But I don't know what it is. Anyway, it was weird and perplexing.

Users are mostly safe. Especially, since there are legitimate/legal uses, for youtube-dl. The legal battle against this software/code is slow. It is also deplorable. The users don't re-share the content, during the act of capturing it; like with eMule/Bittorrent/Gnutella. It has always been more lucrative to pursue the provider, over the receiver. Youtube-dl should enable ad support, in cooperation with Youtube. It already supports user accounts. Then it is up to the user, to edit out that support. We all have the potential to do the same thing, with any browser. You might even "still" be able to do this with browser plugins.

I'm looking for a FFmpeg release, newer then Sherpya's 2011, compatible with Win98. But, until then, there is LibAV. LibAV is very similar to FFmpeg, as it was a controversial fork. The command names are different, but the arguments/options are close. For example: FFMPEG would be AVCONV (AVCONV -I FILENAME -C:V H264 -C:A COPY FILENAME), and FFPLAY would be AVPLAY. The last version of LibAV, that works with Win98, is 11.3. However, it was not complied with SDL support (AVPLAY). But that can be fixed, without recompiling, by also downloading 10.1. After extracting both archives, enter the 10.1 "bin" folder > rename "AVPLAY.EXE" to AVPSDL.EXE > copy both AVSDL.EXE and SDL.DLL to the 11.3 "bin" folder, and then get ready to dust off your Hex editor. You'll also need a copy of LIBGCC_S_SJLJ-1.DLL placed in the 11.3 "bin" folder. AVSDL.EXE is linked to older LibAV shared libraries. But this is relatively easy to fix, since they are only one version number different. For example, it may ask for AVCODEC-55.DLL, but the new one is AVCODEV-56.DLL. So try to run AVSDL.EXE, then use your editor to search for and rename the missing library (AVCODEC-55.DLL > AVCODEC-56.DLL). There are about five different DLL strings to search/rename. It may not be necessary to rename AVPLAY.EXE to AVSDL.EXE. I've only done that, since I've only been able to test the 11.3 version with a non-accelerated video driver. For me, it only gives a black screen. The modified SDL 10.1 version worked fine. If you are using a 3D card, with proper accelerated drivers, the 11.3 version might work. Still, renaming allows both options. I'm not sure how the 11.3 LibAV compares with the 2011 FFmpeg. The date of the files, in 11.3, vary between late 2014 and early 2015. Sadly, I'm not sure if LibAV can capture the Desktop. The 2011 FFmpeg version came out before the Dshow Desktop Capture source commit. Likely neither can be used for capturing the Desktop to video. I think Mencoder, from Mplayer, can do it. I haven't looked into it yet. VLC can do it, but it is slow. Also, there is Virtualdub. But, it doesn't capture, with my video driver. It seems the FFmpeg/LibAV break, with Win98, happened when people switched to MinGW-w64, for building Win32. If I get around to it, I'll see if I can't budge out a newer FFmpeg or LibAV, with the old MinGW; unless someone points out an already existing one(s).

Excellent! Glad you are the sharing type @SweetLow.

I respect your opinion. If you want to expound on your intrigue, no invitation is required. Not that you have to. As is, it is still amusing.

The are some wires to untangle. Vbemp does have 2D acceleration. And that does make a difference. Some older cards, supporting Win3x, did have 3D acceleration. But those that did not, could still play video. Those old videos you've mentioned, are also encoded is a much less complex codec. They system resources, for playback, are much lower. Also, the quality was pretty low. The redraw demands where much lower. There are modern codecs for Win98+, to a degree. But that does not mean your browser can use them. I "personally" don't know what K-Meleon can and can't do. I know newer versions come with codec downloads. Maybe for systems with different SSE capabilities? But, I don't know if that is of any use to the older version. There is the Ringo Mplayer builds. They are newer. I have yet to get any of them to run. Not that I have tried very hard. So you might have luck there. So it probably isn't fair for me to say, that the last supported Mplayer can't handle modern codecs. Edit: The newest Ringo Mplayer build works fine. Keep in mind, Youtube offers several encode types. Occasionally, I've tried to watch something, with a new low priority encoding(AV-1?), and for whatever reason the typical encode types were not available. In this case, I would have to download the Video/Audio and re-encode it myself. From what I can tell, most videos should still work(h264/AAC-LC). As it is for all of us, that post on upstanding forums. The legality changes from country to country, and more concerns the tool(s) creators and their hosting providers. I haven't heard of a person getting in trouble, for using those tools. But I haven't been looking either. The issue with those tools, is that ads are not included. Additionally, content under copyright can be stored locally. I can not say this is true. I haven't tried. What I can say, is that Vbemp may not be your problem. I can say this, since I've had no problem playing most modern encode types. The issues I have had, are when I cannot select less complex video outputs (like SDL). And that "is" related to Vbemp. If a browser has no option to disable accelerated video, or has no updated codecs, that can be a problem. But my experience here, is related to Chrome/Firefox types on modern systems. I don't know what K-Meleon is doing.

It really just depends on the CPU and the browsers configuration/requirements. Unless you are talking about high resolution video. Then all bets are probably off. Mplayer (port from Linux) can play videos, with same the compression format as used by Youtube, without Accelerated 3D drivers (Vbemp). I am not sure about MplayerWW (Mplayer with nice GUI). MplayerWW's UI settings panel seems to only support accelerated settings. But I would think the non-accelerated output could still "somehow" be set; provided those outputs were not disabled at build time. Some Youtube videos include only codecs not likely to play in current Win9x browsers, or even with Win9x supported Mplayer. For now, that is probably going to be the bigger issue, not video acceleration. With the age of the browsers you listed, it may be the exact issue. Anyway, most modern browsers presuppose an accelerated video driver. But they tend to provide an option to disable using video acceleration. Depending on your video card, some browsers perform much better with video acceleration disabled. I don't know about K-meleon, this is just a general statement towards all systems/browsers. There are other ways of obtaining Youtube video streams, without a browser, but the legality of those ways has been highly debated.

I'd say the average "Windows" users didn't really acknowledge that a Java application they used, could likely run on another operating system. But there were hobbyists writing Java applications. Maybe because they didn't pirate VisualBasic, and Java was free. For most of the uninitiated, Java seemed something like VisualBasic; even though they only had a few things in common. But, if you weren't contemplating the multiple platform aspect, you where likely only looking at concepts like bytecode. From a programming point of view, VisualBasic made for faster development of light-ish applications. But Java was a more expressive language. VisualBasic could use the native U.I., in a Rapid-Application-Development like style. Still, Java's U.I. tended to be more expressive. The run-time penalty was higher for Java. And Java was bulky. It did seem like Java gained some popularity, when VisualBasic was initially killed. I don't think it ever got as popular as Delphi, untill after Delphi initially died. C++ was king. I think 2005-2010ish Java seemed to gain some average user traction. It probably started with the switch to JAVA, in AP Computer Science classes (2004). For a short time it was C++ (1999-2003). Starting in 1984, it had been Pascal. I don't have any hard data to follow. But I wonder where Java would be, if it hadn't been for its long standing place in education. It is still there, today. If some other language had be used, would Minecraft have still been written in Java?

That is a kind of "wide open" question. -Why did they not charge for it? They can charge for several types of support. It should be noted, some features were developed to meet "paying" client needs. That kind of support is worth a lot of money. Also, having a developer walk you through your difficulties, while using their product, isn't something you'll often get for free. Especially if it is a big project, you needed done yesterday. -Why did they build it in the first place? To make a standardized platform, on top of platforms that are incompatible. Looks good, If you need something to work; but you don't want to rewrite it, for every platform. Why did they make it for Windows, and not just for *nix and Apple/Mac? If you are going to sell advice, on using a wrench, that advice should apply to as many cars as possible. Although, I'm not sure I would consider Windows users deserving? And considering the result that Java is, I'm not sure what kind of respect it is, that you are insinuating the users/companies deserve. You can hold others in poor or low respect. If Java is the symbol of that respect, I am not sure that you are saying anything nice about Windows users. Note: I mean this all kindheartedly. No actual terseness is intended.

I really should have started my own thread, about running from USB. For my part, it's running from memory; but booted from USB. I run most Win9x systems this way, but not always booting from USB. This is just another note/update. I recently ran into, on and off, blue screen parity errors. On this particular machine, I was using memdisk (Syslinux) with Grub2. It could've been an issue, with the shared Video memory. It is fixed in BIOS at 32mb. I think it was more likely something to do with how Windows/Himem.sys calculates available memory, when using some memory for a HardDisk image. The machine has 1.5gb of RAM. The disk image is 300mb (on the dot). When Windows did successfully load, it would report around 1200mb of memory. After loading, there does not seem to be any stability issues. There is probably some hardware/software initializing sequence, that determines the pass or fail. My assumption would be that this is "more" related to my hardware's initialization. By the time Windows gets a chance to load, the difference between pass or fail has likely already been set. Several memory sticks were swapped out. Some 512mb and others 1Gb. I never tested with only the built in 512mb (this is a laptop). Memory tests cleared the memory as healthy. I am running with Rloew's memory patch. The solution has been to set "MaxPhysPage=", in SYSTEM.INI, and under the "[386Enh]" section. When you figure the amount to set, the drive image must be included in your calculation. You do not set how much memory you expect to see reported in "System Properties". You set that amount, plus the HardDisk image amount. Take the total desired amount, in megabytes, multiplied by 256 and converted into hexadecimal. There is now no occasional parity error, and I have near total memory available. I wasn't sure it that was going to be the case. I started with a setting well below the total amount, and then worked my way up. As this is a live HardDrive image, I could've saved and booted the "live" image, after each adjustment. I just used Qemu, from the live environment, and booted the stored image file to Dos. The Dos text editor provides a quick modification path, to "SYSTEM.INI". This saves on USB writes and time. There may be a different solution. For now, this seems to work great.

Yeah, that is a pretty clean fix. Good job. There should be an emoji, like the one above, but with embarrassed red cheeks. That way the eye roll is directed at self, and no one else. Though, its pretty silly that I nitpick it.