DOS ain't dead

Did anybody check the SDL library whether is easy or hard to make a DOS port of it. It is strange - there are many bizzare operating systems supported but DOS isn't.

http://www.libsdl.org/

EDIT by rr: changed subject from "SDL"

---
DOS-u-akbar!

> Did anybody check the SDL library whether is easy or hard to make a DOS
> port of it. It is strange - there are many bizzare operating systems
> supported but DOS isn't.
>
> http://www.libsdl.org/

AFAIK SDL is a wrapper library, it doesn't include any OS specific code. The principal problem is that I don't know any good standard threads library for DOS. I didn't have the occasion to try FSU Pthreads and the GNU Pthreads port doesn't work too well for me, it is slow and often crashes.

---
Glory to God for all things

> > Did anybody check the SDL library whether is easy or hard to make a DOS
> > port of it. It is strange - there are many bizzare operating systems
> > supported but DOS isn't.
> >
> > http://www.libsdl.org/
>
> AFAIK SDL is a wrapper library, it doesn't include any OS specific code.
> The principal problem is that I don't know any good standard threads
> library for DOS. I didn't have the occasion to try FSU Pthreads and the
> GNU Pthreads port doesn't work too well for me, it is slow and often
> crashes.

Quoting Japheth's page (http://www.japheth.de/HX.html) :

"About SDL
SDL (Simple Directmedia Layer) is an Open Source effort to provide a multi-platform API for games, emulators, .... There are ports for various platforms available. As far as HXGUI is concerned, support for video, (wave) audio, keyboard, mouse, timer and threads is implemented. _Please be aware that there is no special version of SDL for HX (or DOS) available. It is the Win32 port of SDL which can be used with HX._ The SDL site is at http://www.libsdl.org/index.php, where the source code of all ports can be found."

P.S. The only problem with that is that it's probably compiled by MinGW, i.e. requiring the non-free MSVCRT.DLL. I think most DOS-related media stuff usually just uses Allegro for convenience (although obviously porting SDL stuff to that isn't as easy).

EDIT: Khusraw, I haven't tried yet, but if you want to attempt to compile FSU Pthreads, try searching the comp.os.msdos.djgpp archives for Ken Wang. He had some tips to build it (c. 2002) that seemed useful. It's been on my todo list to try, but I haven't gotten a "round tuit" yet.

EDIT #2: I forgot I can just give you the link, duh. Here.

> EDIT: Khusraw, I haven't tried yet, but if you want to attempt to compile
> FSU Pthreads, try searching the comp.os.msdos.djgpp archives for Ken Wang.
> He had some tips to build it (c. 2002) that seemed useful. It's been on my
> todo list to try, but I haven't gotten a "round tuit" yet.
>
> EDIT #2: I forgot I can just give you the link, duh.
> Here.
>

Thank you for the link, but if I would have had enough knowledge about GNU makefiles and scripts syntax perhaps I would have had compiled SDL with DJGPP until now. Sadly now it's too late to learn the syntax, I have neither the time nor the interest. Last year, when I tried to build Mplayer with pthreads enabled IIRC I found that link, but the information wasn't enough in order to successfully compile FSU pthreads with the DJGPP package I have installed (which usually contains the latest ports of GNU tools).
Edit: I've remembered that the principal problem was that FSU pthreads assumes DJGPP lacks some functions which now it have, so it was a complete mess with the defines and header files. Anyway, if I would really need a FSU pthreads compilable with the actual DJGPP package, I would ask Michael Kostylev for the patches.

---
Glory to God for all things

> > EDIT #2: I forgot I can just give you the link, duh.
> >
> Here.
> >
>
> Thank you for the link, but if I would have had enough knowledge about GNU
> makefiles and scripts syntax perhaps I would have had compiled SDL with
> DJGPP until now. Sadly now it's too late to learn the syntax, I have
> neither the time nor the interest. Last year, when I tried to build
> Mplayer with pthreads enabled IIRC I found that link, but the information
> wasn't enough in order to successfully compile FSU pthreads with the DJGPP
> package I have installed (which usually contains the latest ports of GNU
> tools).
> Edit: I've remembered that the principal problem was that FSU pthreads
> assumes DJGPP lacks some functions which now it have, so it was a complete
> mess with the defines and header files. Anyway, if I would really need a
> FSU pthreads compilable with the actual DJGPP package, I would ask Michael
> Kostylev for the patches.

M.K. is unresponsive, so no luck with him.

Anyways, I found a compiled version of LIBGTHRE.A inside GNAT3104.ZIP inside EZL1998F.ZIP on Simtel under /ada/ (here or here, srcs here). I haven't tried using it personally, but I assume it's worth a try! (If it doesn't work, try again with DJGPP 2.00. I think the conflict with later versions is some extra added signal handler.)

> AFAIK SDL is a wrapper library, it doesn't include any OS specific code.

SDL supplies an OS-independent API for video, audio, timer, keyboard, mouse, ... resources. However, that means that SDL itself contains OS specific code. So just trying to compile it with DGPJJ probably won't get you anything useful.

---
MS-DOS forever!

> SDL supplies an OS-independent API for video, audio, timer, keyboard,
> mouse, ... resources. However, that means that SDL itself contains
> OS specific code. So just trying to compile it with DGPJJ probably won't
> get you anything useful.

My English is not so good to know exactly the extent of the word 'contain' semantic aura, but I would say that SDL 'wraps' OS specific code. It was out of question that just by trying to compile for DOS the unmodified SDL source code, as it is now, you couldn't have any useful results. I wanted to say that is relatively easy to patch SDL's source code so that in case 'DJGPP' or 'DOS' is defined, to make it use existing DOS libraries (e.g. Allegro in lack of something better) for video, audio etc.

---
Glory to God for all things

> M.K. is unresponsive, so no luck with him.

I noticed myself that Michael is less solicitous than he was, perhaps he has reasons for this.

> Anyways, I found a compiled version of LIBGTHRE.A inside GNAT3104.ZIP
> inside EZL1998F.ZIP on Simtel under /ada/
> (here
> or here,
> srcs here). I
> haven't tried using it personally, but I assume it's worth a try! (If it
> doesn't work, try again with DJGPP 2.00. I think the conflict with later
> versions is some extra added signal handler.)

Thanks, shall give it a try when I will have time.

---
Glory to God for all things