awkduck

If your audio device is not supported, you might have another option. This is most useful on laptops, but it isn't always pretty. Many of you will already know about this. But until a couple of years ago, I didn't. Most USB audio devices (cheap ones) are supported by the Windows "Generic USB Audio Device" driver. But its not perfect. Here is a description on USB audio, from Microsoft. It is also a WDM driver. So performance may be chunky, depending on your system. Some systems I have tried, end up with choppy audio. For example, window's sounds will stutter, but synth is fine. Seems to be more a problem on Virtual Machines. Using a ASIO driver may help, if you application supports it. Good luck!

Here is the Roytam1 fork on github.

I'd be interested in the sources for the mod, and maybe which tools are used to compile it. I've also noticed that it cannot play an mkv that has ogg as the audio stream. Sherpya has built many Mplayer binaries for Windows. From the "old" folder on Sourceforge, one of the last builds (maybe the last) from 2010 seems to work pretty well with Win98. I would recommend reviewing the mplayer config file and associating mplayer.exe with the desired file types. It also works with the Hxdos extender on dos. But the forked version (hxdos), with support for ac97 and hda, is probably required; for most people. It does not work on Win95. I have also been able to use Mplayer, from the Freedos distro, inside a windows Dos windows. It needs to be a fullscreen Dos window. Depending on your video card support, for vesa access via a Dos windows, graphics may become crippled; when you leave the Dos window fullscreen mode. I have not tested it with Win3x, but it has worked with Win95. Edit: I suppose you could use newer versions of Sherpya's Mplayer, with Kernelex. And for anyone attempting to use Mplayer for Dos, keep in mind that it "does not" use Window's acceleration and "does" use Window's soundblaster emulation. Not ideal for slower computers. It's really more of a novelty.

I second Bruninho. I ran into something similar back when checking out the Lynx web browser. The homepage had a small graphic icon "Viewable by any browser". After looking around it turned up this Campaign. The link provided by Bruninho is more progressive and Retro targeted. But retro business aside, its an example of people creating the web they want. Rather than just complaining about JS. What would be really cool is a resurgence of Hotline or things like it. There was a small moment when people were integrating homepages into things like gnutella. Fear of exposing your real IP and the explosion of piracy's immediate gratification gave rise to bittorrent/filelockers and server based social networking. Now some really cool networks are gone or held up by dedicated grey beards, aided by a curious few. Modern devices all but put the final nails in the coffin. B.B.S. is dead, long live B.B.S. But back to Web 1.0, it would mostly support even dos webbrowsers. You could likely even use Amiga and a couple of 8bit systems, to view some content.

I've recently had luck with "VDMSound.win9x.bin.alpha3.zip", when using WDM drivers. Probably works with VxD drivers, too. It is just stitched together enough to work. There is some reg addition needed to kill the tip of the day. Once you understand how it is put together, you can fix it up to your needs. I've never tried the original VDMSound. It is for Win2k and up.

I'll be sure to add it to the collection. Is that a recent discovery, or did you pull that from memory? Good find, either way.

Hmmm. But it doesn't do this when you load a non-D3D game? If you are getting different video initiation on the host side, then you might have your answer there. Do you know what I mean? Edit:You could test your WineD3D build on other VM software (or real machine if available). This way you can determine if it works in it's own right (absence of pass-though). Others might even be willing to test, too. It it ran, it would be slow. But it could eliminate one variable in your process. This edited suggestion has nothing to do with the above questions.

So we could distill this down to, compiling newer versions of WinD3D for WinXP and Win98? And you are suggesting that he altered them in no way, for compatibility with his Qemu fork. But obviously they are altered. Unless you are suggesting that no one ever tried to target the newer versions to build for the older versions of windows.? Meaning you believe no one has actually bother compiling the newer versions (WinD3D), to build for (target) the unsupported versions of Windows. But he has tried, and had some success. Is that about it?

Thanks for looking into it :) They would probably work okay with Win98 and kernelex. But, with some trade offs, other might work better. Bochs works on Win95, but is hardly very useful. After Qemu 0.10.1 accelerated virtualization was moved to KVM. Qemu still works without KVM. But as version numbers increase the evolving compilers build less efficient binary(faster CPUs often more than make for the difference) and non KVM performance is less a focus. So in my tests, Qemu provides less performance beyond 0.9 and 0.10, unless you have a KVM capable CPU. Kqemu provides similar benefits to KVM, but doesn't require a KVM capable CPU. It doesn't compare in performance or features, but it is way better than nothing. Qemu with Kqemu is similar in performance to Virtual box, without KVM (Maybe Virtualbox 3-ish). You're not gonna wanna play heavy games through it. But it could still be very useful. Qemu dropped support for Kqemu after 0.10.1, to focus on KVM. So any version after that has no option for kqemu, without manual patching and rebuild. I am sure Kqemu >=0.10.1 would work with Kernelex and Win98. I am not too sure about Kqemu (maybe). But if you use Win95, you'll need to do some work. Maybe not that much. Kind of like Dosbox for 95/NT. It takes a bit of love. An older version of Qemu (without Kqemu) would perform worlds better than Bochs. As a Win95 user, I'm primed to want an alternative to running Win98/Kernelex or Bochs. Which seems to mean I need to roll up my sleeves. Without Kqemu, I can use Qemu >=0.9 under dos using with HXDos. I can even have sound, with a non-official version of HXdos. But depending of host card's VESA design, SDL can produce hairy results. Also, dos doesn't provide 2d VESA acceleration. On a machine with Windows 2D acceleration, SDL would perform more than well enough. As can be seen with the unofficial Dosbox build. The trade-off with older versions, is occasionally running into unimplemented hardware emulation. If accomplished, Qemu with Kqemu, would likely perform better than newer versions using Kernelex on Win98. And on 95, just about anything would be better than Bochs. Sorry Bochs, but its true.

You might not be interested in trying anymore. So I apologize if this reply bares no interest, as you specifically said you need someone to do it. I understand that, and have been there. But if no one comes along, you could list more details of the method(s) you tried, and the errors you ended up with. If nothing else, this provides someone (that knows what's going on) insight into the situation. I would certainly offer assistance, but I've yet to actually build anything Windows related. I'm nearing that point. I've been able to work out a lot of other compilation issues. I have never written a complex application, but can modify the heck out of one. So I'm not promising I could help much. But I'd for sure give it the time of day. I'm sure there are plenty around like that. Probably more competent than I. On a side note, I myself am looking into building Qemu 0.9-0.10 for Win95. Something before KVM came along. Maybe even get Kqemu for Win95. Although for completely different reasons. If someone else has already done it, feel free to gloat :)

I have this 2003 era laptop, with soldered ram (512Mb). But the initial 640k (and some above) are fine. The laptop includes an additional 512Mb memory stick. With Linux I can use a kernel boot parameter (mmap) and tell the OS to ignore the bad on board memory range. It runs very stable that way, other wise the motherboard heats up and the usual bad memory issue arise. What is the best way to deal with this in Win9x? A himem.sys configuration? Or maybe eat up the bad memory range with a ramdrive, that I never use?

These days, I am surprised someone doesn't sell printer kits. Some 3d printed parts, a couple of servos/motors, and a micro controller or small FPGA. We could be making printers for Dos. Might even be easier. Drivers seem harder to write, the more modern the OS. Well, that is unless you don't have the toolchain, documentation, etc. I suppose it would cost more, than a new printer. But that's pretty common, in the obs"ELITE" world of computing. Seriously, you'd think opensource printers would have been a thing by now. Some silly Slogan, "The FREEdom to print, Richard M. Stallman". I suppose he is more a free software guy. But the firmware could be opensource.

LoneCrusader, long time fan of the 95 work the two of you have done. I fortunately have one legacy port :)

The same driver supports 98 and 95. But either Win95 support is poor, or it doesn't support DirectX8(very well).

Yes, I have one of those (Sx0). I think the chip (V30) is a P4M800. There are plenty of handy tools for finding out specs. But A nice easy one is KolibriOS. The chip is displayed on the blue kernel boot screen. Once booted, there is a pci info tool that lists manf/dev ids. Its not bad for a 1.44mb OS. Any memdisk bootloader or direct map should work, for the 1.44 floppy img file. It has more applications from an addon pack (Doom/Quake/FFplay). But for me it is a nice quick tool for moving files from fat/ext*/ntfs to fat32. It has pretty good USB support and is only booted as a ramdrive. I totally hack the desktop, because its a bit cluttered for me. Hope no one minds me selling this thing, while posting in a Win95 section. As a Win95.... fanatic, Kolibri has been almost as useful as Grub4dos. Though there are probably plenty of machines it won't work on.