awkduck

Ironic. Three years ago I began digging up Win9x/Dos. Right about when Linux started acting more and more like modern Windows/Apple. I admit, it still has a long ways to go. Switched to the BSDs for awhile. They seemed more pleasant to lean out, when compared to something like Archlinux. The future is looking bleak. Anyway, I liked your Linux description. I had written one similar to it, but chickened out and went simple.

On the blog page, for KernelEx, "Retro Systems Revival" makes mention of the prerequisites. A readme distributed along with the release might not be a bad idea. But most are pretty grateful that the release even exists. Some have had stalling problems with 3.66. But that seems to be mostly a Virtual Machine issue. Killing the "old app (I think that is what its called)" process moves things along again. Don't know if that is advisable. To avoid that issue some prefer 3.65. Both come with KernelEx. So it is likely that you will be fine. Just be sure to read the instructions provided by the installer, during execution. You'll see what I mean when you run it. Linux is easy and hard. Good advice and/or research skills (man pages) can get you a long way. Linux is HUGE, its easy to get lost. But it is very flexible. Hence, user created video game console distro's (RetroArch). Smaller live Linux distro's can be easier to start out with.

I've had issues getting certain AC97 hardware to correctly initialize while using the correct WDM drivers. This was on 98FE and SE. Sometimes it seems like later hardware has sloppy backported driver support. Even though the drivers come from the correct OS version folder, the problem seems to resolve when using Rloew's "wdmex". This seems more often the case with FE. So I understand your WinME solution. Just thought I'd throw that out there. Maybe it'll be useful to someone.

It certainly works well, when people can match communication modes. What you describe sounds like a "Project" mentality. The kind of conversing found in a bug report thread. But even then, it helps if people have similar wiring. For example, three replies can give the same answer, but not every reader finds it in each. Way cool!

I wonder if we all do that a little. We attend to the problems of others, from our own experiences. And sometimes our advice may be colored by whatever our current projects are. I have wondered if some people, in the Win9x section, are intentionally sending others on a wild goose chase. Or providing information that leads to a dead end. But, since there are few of us here, I imagine it is more that we want to help one another; even if we don't know enough about the topic(s). It is also possible that personal bias will prevent us from helping someone achieve what we see little point in, or maybe even disagree with. Although, for some of us, we are doing exactly what we were when Win9x was more current. Socializing with "Win9x" dogma and opinions; be it for aiding or arguing. Some of us will probably find a way to keep doing that, right on in to the "Rocking Chair". That seems to be how it works out with any beloved hobby (talking shop). Language barriers can make trouble, but we all use these technologies differently. And that in itself can create another barrier. What may apply to your traditional setup, may make no sense to someone else's. Years ago, coming from a tech position, it was common that I had to help people setup up their machines, for specific needs. Often I configured systems/networks in ways that I would never chose to on my own. I knew they were going to have problems with that setup. But for some reason or another, someone somewhere wanted it that way. And it was my job to give them what they wanted. If you've ever had to help "fix" a family members PC, you probably know what I mean. The issue you resolve can often be caused by something that the owner will keep on doing. Or worse, the issue comes from the exact way they desire the system configured. It can be annoying. That annoyance is our own pride, while claiming we just can't tolerate ignorance. I suppose that's because we are all kings, right? I know this is way off topic, so I'll put a sock in it right here. You guys aren't trying to debug people :)

Retrozilla might work. I think you need to select the SSL option.

There is a very basic program called "Portable Application Creator". I don't know if it ever worked with Win9x. Also "Portable Application Launcher". Interestingly, similar to portable applications is application virtualization, like "Thinstall" (the pre 3 versions supported Win9x).

There was more then one project. Most of them came together as forum projects. Eventually, a few had their own websites. But those are long gone. I can't remember any of their names. There is still "portableapps". They ended Win9x support in 2010. But their tools don't really seem to support the creation of portable applications. They just provide a uniform system for deploying them. I would still do all the things I already do, but just format my package/launcher to their specifications. That isn't very important to me, as of yet. Most of the toolkits were just scripted GUIs, doing what I manually do now. Some were far better then others. There was one that gave you the option to have your registry and changed (portable) files in a hidden folder; named after and located in the same directory as your launcher. But it also provided an option to temporarily load the same data, but then store changes back inside of the launcher file. In both cases the portable application was just one file. There are advantages to both ways. That is how I build them. But it adds some steps in the creation process. Other toolkits often output "portable applications environments" working out of a folder. The main advantage of this method, was that you could view the files like you would in the "Program Files" directory. Also you can overview the portable registry files. It was easier to convert this kind into an actual installed application, if you wished to do so (batch file).

It makes perfect sense. And it makes sense that DosBox would name their project that. But it is still a pain :(

Years ago, I had a handful of ToolKits for making portable apps. As life has progressed, those tools have been lost. Back then I didn't use them much anyway. These days, I often run Win9x from a disk image loaded to ram. But I install programs elsewhere. I can save my settings to the "Live Disk Image" using a couple of different techniques. This saves, the sometimes needed, registry settings. But it is much more practical to create a portable application. In fact, a Live environment is great for that. Right now, I use a bunch of individual tools and notes; collected from various places. It works fine, since I can fine tune each application to it's needs (very hands on). But I was just curious if anyone still had some "Old School" portable application tool kits. This is low urgency. But high curiosity. For the record, this is for personal use and not for the distribution of copyright protected software. In the configuration above, portable applications are obviously a practical solution. In point of fact, this configuration maintains a very clean system registry.

I did notice that some (like 915.inf @ ICH6/win98se) are sparse, like you have said. But others do have registry entries, for configuring drivers (like ich4core.inf @ ICH4/win98se). Some specific windows files are specified for use. But perhaps windows already installed the same. I suspect that is what it ich4core.inf is doing with APM. It removes the driver and only (re)installs it if it is detected/verified. I would guess that most of these drivers work fine "as is" most of the time. Sometimes, settings other than the default may need to be used. As for when the inf files specifies using certain Windows' drivers, for all I know they are the same that Windows would have specified. It does list files to remove, that it does not reinstall. So in some cases it may be anticipated that incorrect files may have been installed or are not needed.

I agree that it is not a driver. I suppose writing "after other drivers" suggested thinking it was. I have had a video driver not work, until the chipset was installed. Windows would boot to a black screen, unless you installed the chipset before the video driver. While researching the issue today, I found instances similar to my own. Sometimes it was related to APCI problems, rather than video. I don't know if VIA chipset installations are different. But I have also had the above video driver issue with Via. With this machine, windows assigned the AGP port as a PCI device. The chipset inf files resulted in it being recognized as an Functional AGP port. No actual driver files of any kind where copied over. But for what ever reason, the video driver worked afterwards. Perhaps there is some brief specification information installed with the chipset? Or associating vendor/hardware IDs with already existing windows drivers, that otherwise may not have been associated?

The "Intel Chipset" is meant to be installed right after a fresh install. I was looking into the issue of installing the "Intel Chipset", after other drivers have been setup (Windows default and third party). I haven't tried it myself, yet, but it seems the "-OVER All" flag might do the trick. Example, "Setup.exe -OVER ALL". This should work with the "infinst_enu.exe" file, but you may have to use the "-A" flag first. Example, "infinst_enu.exe -A -OVER ALL". Otherwise, you can just use 7zip to extract the contents of the self-extracting executable (infinit_enu.exe), then run Setup.exe directly. Supposedly, "infinst_enu.exe -A -A (optional -P [output directory])" will self extract without running setup. Without the optional "-P" flag, the contents should extract to "C:\Program Files\Intel\Infinst". I wonder if this would help with Windows installs ran without the "Setup.exe /p i" switch? Would it correct ACPI issues? As a side curiosity, I have wondered if installing the "Intel Chipset", enumerates pci devices not listed in device manager; on machines where using "Setup.exe /p i" did not do so. I'm sure I will find out soon. Other drivers might need to be re-installed, to correct issues from the chipset having not been previously installed correctly. Anyway, a complete list of "Intel Chipset" install flags is located in the "readme.txt", found with the chipset installer (compressed inside infinst_enu.exe). Anyone have experience with this?

One day I'll dig my hands into those features So much to do, so little time.

Actually, that has been a real annoyance for me. Its been called a "dos box" for awhile. When researching Windows internals (Win3x-9x) many books do refer to it as a dos box. It can make using google almost pointless, as DosBox/DosBox-X will return in most of the results. It makes trying to understand what happens when you run command.com very obscure. This since command.com is ran inside the dos box, not the actual dos box itself. I guess there is a ReactOS cmd.exe, for Win9x, that initializes a similar environment. Reading the source code for that might give me some clues. I have so many projects, that I haven't continued to research it. Looking to get three books, Undocumented Dos/Windows and Unauthorized Windows 95. Maybe they'll give greater detail. But, in this case, it is the win32 side of things I'm interested in. The same problems you had when running shell replacements?

Which driver? VGA 16 Colors? It probably does not matter, but could you type mem at the command prompt? Then tell me how much free conventional ram you have.

jaclaz, thanks for the excellent reading material. Lots of good energy in those posts!

I haven't used BB4Win much. But LiteStep never caused me any issue. There are other shell replacements I've tried, that had many issues. But I imagine if a person's Windows configuration relies heavy on explorer, they would be much happier using the explorer shell. I run a pretty lean install. Long ago, I used to run with Program Manager as my Win98/XP shell. With XP I had to save the XP original progman.exe file, since SP1 replaced it with a non working version. But I had no systray, when using Program Manager. I found something called "Rocket Tray". Or I think that was it's name. But Litestep had it's own systray and on the whole was quite light. But none the less, your XP like start menu, with the MS-Dos Prompt, deceptively looks like an improved version of XP Or maybe not so deceptively

You might have better luck with the newer versions. It could also be that there was an error installing the driver. VGA 16 colors is the default VGA driver that Windows reverts to, when there is a problem. Since VBEMP supports 32bit color, I would suspect the driver is not compatible or did not install correctly. But even the windows VGA16 driver may be enough to tell if the issues is your ATI driver. Wolf/Sod should still work, even if only 16 colors. Remember, VBEMP and VGA16 is not meant as a fix. Just a test to determine if the ATI driver is the issue. If you get the same blackscreen with VBEMP/VGA16, then you know the ATI driver is likely "NOT" the issue; since the black screen affects all video drivers. Not as far as I know. But I am glad you have sound.

If someone could write a more "hardware direct" and "non CPU emulated" win32 dosbox, then HxDos 2.17+ (Ruslan Starodubov) would be a possible option. It would be a nice project, without the interest of using it with HxDos 2.17+. Just not architecture portable.

Joaquim, wolf4gw does not always automatically enable sound, when detected. You need to change the settings in the "Game's" sound options. If soundblaster is not detected, you may not be running VDMSound correctly. Some "Extra" notes on VMDSound: 1. From the "Same" commandline window that you run "dosdrv.bat", you need to change directory to where you have "wolf4gw.exe". Then run wolf4gw. Otherwise soundblaster may not be detected. 2. You can unload VDMSound by running vxdsboom.exe. 3. The "Tip of the Day" error, when running dosdrv.bat, can be fixed in the registry. REGEDIT4 [HKEY_CURRENT_USER\Software\Freeware\VDMSound] "NextTip"=dword:00000000 "TipsFile"="C:\\Program Files\\VDMSound\\VDMSound.tips" "ShowTips"=dword:00000000 You can either create a .reg file with the above in it (and double click it), or add the contents manually with regedit. 4. The reason wolf4gw may be working for you, may have to do with conventional memory. Original Wolf3d and Wolfdosmpu both require that you have enough conventional memory. Wolf4gw does not. I believe wolf4gw also supports vesa modes, that the original Wolf3d does not. This is more likely the reason it works for you. If VBEMP fixes the black screen issue, with the original Wolf3d, then your ATI driver may not be supporting the needed modes. I think someone has mentioned that to you before, in another thread. An older or newer ATI driver may fix that issue, since VBEMP does not support "3D Acceleration".

Looks like you had fun. Reminds me of CalmiraXP for Win3x. I haven't gotten around to it, but eventually I'd like to mess around with BlackBox4Win and LiteStep.

If you mean the links for VBEMP, try the middle [?] link. The first ones are dead. Try these command line arguments first. For audio you can try "sod4gw.exe nopro", "sod4gw.exe nosb", "sod4gw.exe nopro nosb", and "sod4gw.exe noal". For your original Wolf/Sod video issue, you can try "wolf3d.exe comp", "wolf3d nocomp", and "wolf3d hiddencard". If any of these fix the video issue, you can try the audio arguments with it. Example:"wolf3d.exe nopro comp"

What fixed the Video?

You are welcome. I hope it/they might be useful to other users, as well. For the sake of clarity, on the "Other Forum" they are suggesting that you "Throttle" the CPU down. I'm sure you understood what they meant. But since people here may not have read your thread "over there", I though it would help to clear things up "here". Most people "here" would assume you mean the Windows 9x CPU patch. Which is completely different than slowing your CPU down "Temporarily" to troubleshoot/play a game. Some "Older" Dos games "do" need a speed tweak, of some kind. I do "not" think Wolf/Sod should require it. If you can run the games in "pure" Dos, even if without sound, then likely speed should not be an issue; in Windows either. But, likely some unique situation(s) exist. Windows adds another layer of complexity, to the situation. Perhaps certain video drivers suddenly support Windows Dos environments better, when the CPU is limited. I apologize for not being more familiar with the "Black Screen" issue you are having. It is highly likely some other user would know more than I. But I have some ideas you could try. It probably won't help, but it has long been suggested to reduce video acceleration, then test if video problems persists. Who am I to argue with many years of trouble-shooters? Just remember to re-enable full acceleration, if it doesn't work. It might not be a bad idea to keep different versions of your video card driver. I seem to remember countless times people needed to upgrade/downgrade their video drivers, to fix various applications, features, and games. It may seem silly, but you could try temporarily installing the VBEMP driver. I've had good luck with the 2010.06.01 version (\VBE9X\UNI\vbemp.inf). On some of my video cards, the newer versions have caused garbled fullsceen Dos windows. But they may work fine in your system. If the black screen issue goes away, then you have "mostly" narrowed the issue down to the video card driver. You could reinstall the correct video driver, and start directing your attention on tweaking that specific device.