Rikintosh wrote on 2021-07-06, 19:50:

If the program crashed, it would close and reopen immediately, without displaying a blue screen, or errors, because the machine […]
Show full quote

Jorpho wrote on 2021-07-06, 19:34:

Well, that definitely wasn't running on a 486, now was it? Don't you think it would be easier to figure out whatever was runnin […]
Show full quote

Rikintosh wrote on 2021-07-06, 18:38:

She used a Win95 or something graphically similar, I don't remember, but it was in Japanese, and she had a system that virtualized everything, every program she had, ran in a virtual "capsule", because if the program crashed, the system wouldn't would be compromised.

Well, that definitely wasn't running on a 486, now was it? Don't you think it would be easier to figure out whatever was running there rather than trying to mash DOSBox into something that it was never intended to be?

Also, what does it mean that "the system wouldn't be compromised"? If Windows 95 is running in some sort of virtual capsule, and that virtual capsule somehow crashes, what exactly is left afterwards? DOS, especially on a 486, is already a single-tasking environment.

Caluser2000 wrote on 2021-07-06, 19:00:

And yes you can play Doom, Hexen, Heretic etc in a separate terminal or full screen...😉

I'm sure you're very proud, but it's starting to seem like you post those pictures in every thread and it's getting kind of weird.

If the program crashed, it would close and reopen immediately, without displaying a blue screen, or errors, because the machine was a kind of server that received files from other computers. Imagine a printer on the network, where the printer was such a machine to work with metals.

I found this out, because I didn't know how to use any of that, as everything was in Japanese or something with Asian characters, I kept clicking on things, until I broke the program, and it was immediately reopened as if it was an x session.But I'm not sure if that was *nix or Win95

edit: the machine was a pentium mmx 200mhz with EDO memories, Trident 3D Image video card, no sound card, intel 430 chipset. I don't have access to that anymore, it happened in 2006 or 2007, many years ago. At the time I wasn't so enthusiastic, today I wanted to build new things for old hardware lovers, I'm studying various possibilities to know what I'll dedicate my development and learning time

I said dosbox, because I figured the closest thing to what I saw on that machine could be something like dosbox.

Maybe the program was just running in a loop in a batch file.

Rikintosh the front end/gui didn't look anything like this did it?

It seems to me that the spirits are a little shaken, I'll leave this picture of the puppies to make everyone happy

Caluser2000 wrote on 2021-07-06, 20:26:

Rikintosh the front end/gui didn't look anything like this did it?

I think so, but everything was written in Asian characters

Rikintosh wrote on 2021-07-06, 21:37:

Caluser2000 wrote on 2021-07-06, 20:26:

Rikintosh the front end/gui didn't look anything like this did it?

I think so, but everything was written in Asian characters

That would make sense because of the use case you described. Some sort of *nix controling everything and the software sort itself of it stops running.. Probably a process or two running in the background that detects the fault and restarts it.

It's the Lesstif Motif window manager (lesstif-mwm) It's based around fvwm2

The official version of DOSBox can run on a 486 but for dynamic core you'll need bare minimum of 64mb, but really 128mb. 256mb recommended.
Since you'd be running DOSBox on a 486 then almost all protected mode games (1993+) are out so likely 64mb is fine, frameskip will be your friend.

For the latest SVN you'll need to use the following to compile, ordered by preference:
1st MSYS w/ Mingw w/gcc 6.3 w/ MINGWRT 5.0.2 for NT3.50/95
2nd Visual Studio 2005 or 2008 for NT3.50/95

Lowest SDL 1.2.15 can go is 3.50 but requires some minor changes to do so. Official DOSBox lowest is NT4/95 w/Active Desktop but can run without Active Desktop and on 3.50/3.51 with some minor changes.

SDL 1.2.14+ is buggy for dinput so either have to use the patch to SDL 1.2.15 fix, use SDL 1.2.13 or have DOSBox use WINDIB.

If you want to use mingw-w64 you'll need to recompile for 486 and possibly may need to use the latest Windows 2000 msvcrt.dll if you use a later version of mingw-w64.

Thank you very much for the information, DosFreak! 😎
- I really appreciate it.

Unfortunately, 64MB minimum are a bit hefty for the average 486 PC, not to say for a Win 3.x/Win32s application. 😔

Personally, I think, the last time that I compiled DOSBox on Windows PC was when it was still using CVS. It was with MSYS/MinGW on XP SP2, I think. 😀

At the time, if memory serves, support for Visual Studio 6 was still around (same IDE as VB6 used)? However, it was deprecated/incomplete already? 🤔
Hm. I did forget. It must have been in the late 2000s, I guess, unless my mind plays tricks on me.

Hm. Maybe an older version, v0.61/0.63 or so could be compiled with VS 4.0 ?

I can't help but the get the feeling that this is a dead end. 64MB memory usage alone is too much for Win32s. 😞

Pity! The idea as such was tempting. A small special version of DOSBox that runs on both Win 3.x and the HX DOS Extender..
But I seriously don't mean to sound ungrateful. Windows 95 (+NT3. 5x) compatibility already is a very good achievement.
No other big project that I know of archived this. Especially not in 2021.