Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

PCI phased out? (Announce)

posted by Rugxulo Homepage, Usono, 08.03.2011, 23:47

Just a few more comments ...

> Vectoring or simple FPU usage according to ABI is a different thing. I have
> to admit that I don't know all ins and outs of that either. I doubt SSE2 FP
> fully lives up to the IEEE standards
"float" (32-bit) and "double" (64-bit) is probably enough, e.g. for most C code. I'm a noob at FPU, so I don't know much else, but I doubt 80-bit precision is necessary for most people. (Then again, AVX??)

> So now I only have BP7 and TS that I occasionally start. (as in less than
> one year). For that, an old win9x laptop serves me right. Still have to
> test these with wine, though in the past the integrated debuggers often
> made emulation hard..
The funny thing is that (apparently) AMD64 is friendlier to Win16 than DOS, which eclipses the former many times over (IMHO). I think most people (?) would agree that DOS had better apps. Then again, I haven't trawled Simtel for old Win16 stuff. (Worse is when a Win32 app has a 16-bit installer, e.g. POW!)

> > WINE 64-bit does run Win16 apps. It didn't say anything
> > about slow emulation. But I haven't tested. Most, if not all,
> > Win 3.x apps are indeed pmode-friendly.)
>
> Probably win32s apps.
I think all Win 3.0 apps were 16-bit pmode friendly. Win32s (NT subset) used PE (not NE), which is not a 16-bit format, so that part should be easiest. Like I mentioned before, I (fairly recently) used Virtual Pascal to compile a Win32 PE with WinCRT (GUI), and it surprisingly worked under Win3.1/Win32s on my 486 (though not if UPX'd). But I also threw in a separate DOS stub compile (Turbo Pascal, 8086) for completeness. Win64 runs it fine, but WINE runs it incorrectly (draws wrong), go figure.

> > However, DJGPP (32-bit) stuff is native speed (e.g. Quake).
>
> Hmm. Some code through a JIT, some not? Or do you use some specific version
> of some extender? Since DOSEMU needs to process the 16-bit extender
> startupcode too, even if the bulk is 32-bit ?
DOSEMU has its own DPMI server, so it does all the lower level stuff and the app doesn't do anything but call the API. So it doesn't have to translate any 16-bit low-level extender stuff since it has its own (native). That's the advantage of a host DPMI, it can do things you can't. That's why a flawed implementation (e.g. Windows) really cripples everything since there is literally no other choice for DOS apps. (DPMI was invented by and for Windows!) But yes, all DJGPP stuff is compiled for 32-bit mode, only the small default stub (2048 bytes) is otherwise, and that is mostly ignored if an existing DPMI server is detected.

I need to setup a bootable USB of Linux64 (EDIT: w/ DOSEMU) one of these days, but I can't quite decide how to do it. :-|

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 400 users online (0 registered, 400 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum