progeCAD: History Vault: My X11 Port to MS-DOS

Many readers are unaware that CADDIT also participates in various splinter OSD projects. One of those is PythonD, a complete port of the python scripting language to the 32-bit DJGPP development platform for DOS. Another of these projects was a (yet another) failed attempt to port a functional X11 GUI framework to the same environment. A pasted IRC chat from the defunct #djgpp channel tells the story:

[bdeck2] The original plan ages ago was to port tkinter
[bdeck2] that meant whiping away the coderot from the DJGPP X11 port
[bdeck2] The mouse IO no longer worked because things moved on to GRX2
[bdeck2] The DJGPP X11 port was still based on GRX1 IO using the old DJGPP V1 IO queue
[bdeck2] The guy doing Kaffe-PC updated the mouse driver for GRX2
[bdeck2] it took me ages to find his shim
[bdeck2] The Port includes a version of the FVWM windowing manager
[RadSurfer] Ok.
[bdeck2] I was able to finally compile tk-wish
[bdeck2] wish.exe running in DOS
[bdeck2] without requiring some third-party app like desqviewx or something
[bdeck2] but I ran into another snag
[bdeck2] I realized that I would have to write custom DJGPP-FVWM wrappers around the window applets.
[bdeck2] I realized that I would have to completely re-write the tcl-terminal from scratch to use a graphical-pseudo-terminal that co-dispayed inside the GRX session with the applet
[bdeck2] or invent a hotkey that toggled between the two with some degree of stability
[bdeck2] I realized my X11 port was hardly a port at all
[bdeck2] but new software
[bdeck2] that nobody, including me, could use
[bdeck2] so that's the story
[bdeck2] k
[RadSurfer] If others picked up and worked with it...I wonder...
[bdeck2] I brought it up once on the newsgroup
[bdeck2] nobody had any real time to make a further go of it.
[Blairguy] so did the fvwm port somewhat work?
[bdeck2] yeah
[Blairguy] could it actually display the graphics on DOS?
[bdeck2] worked good
[bdeck2] I have a hello world demo somewhere...
[RadSurfer] could have interesting applications.
[bdeck2] yeah... if someone wants to play... this would be a fun toy I suppose
[RadSurfer] be really cool if it got itself worked directly into a DOS-OS kernel [hint]
[bdeck2] I'm not sure what you propose...
[Blairguy] dare I ask how big the exe was?
[bdeck2] uhh... about 400K or so I think ... somehow
[Blairguy] wow
[Blairguy] that's pretty tiny
[RadSurfer] A graphic "dos" (ie. 32-bit console) environment. Cool.
[Blairguy] well, if you want that then you can use SEAL2 or OzoneGUI
[Blairguy] or GEM for that matter
[bdeck2] uh RadSurfer...
[RadSurfer] I'm not as advanced as you two...
[bdeck2] there is no console support
[Blairguy] GEM is a 16-bit DOS GUI that has lots of progs written for it
[bdeck2] that was the problem I was trying to describe
[Blairguy] but it's single-tasking
[RadSurfer] it need only display a terminal (ie. console) box.
[RadSurfer] single-thread.
[RadSurfer] hmmm...
[bdeck2] Someone has to write it
[bdeck2] ergo my tkwish port
[RadSurfer] anyways, I wonder if windows got its start like this?
[Blairguy] why not just XTerm?
[RadSurfer] windows 3.11, lol
[bdeck2] I looked at xterm sources
[Blairguy] or rxvt?
[Blairguy] and?
[bdeck2] couldn't find any simple enough to port just using fvwm and djgpp functionality. They were all multitasking socket oriented terminals.
[Blairguy] oic
[bdeck2] for real-unix
[Blairguy] hmm
[bdeck2] see in unix
[Blairguy] a port of GNOME would be cool :-)
[bdeck2] the terminal provides a text environment for a shell
[Blairguy] but that's simply the point where it would stop being DOS and start being UNIX
[bdeck2] the shell is called in a fork and signalled remotely using ... drum roll... the X11 UNIX socket layer!
[Blairguy] so what about WATT-32 for the socket layer?
[bdeck2] yeeessh
[bdeck2] missing the point here
[bdeck2] my DJGPP-X11 is *NOT* a client-server app
[bdeck2] there is NO SOCKET to connect to
[Blairguy] oh :-)
[bdeck2] it is, for arguments sake, a DOS windowing environemnt that very much looks like the old days of sunOS 1.x
[bdeck2] but under the hood, it is *anything* but X11
[bdeck2] the headers are the same
[bdeck2] there is a libX11, libfvwm, etc
[Blairguy] so have you done any other exotic ports?
[bdeck2] but the true client-server multitasking window-manager you think of with X11 simply isn't there.
[Blairguy] ic
[bdeck2] sort of defeats the purpose
[bdeck2] Now
[bdeck2] on the other hand
[bdeck2] itt could prove useful... if tweaked a bit.. for something like the X11 ghostscript driver
[bdeck2] which I fooled with once, go as far as having a white screen up, but that is as far as that went
[Blairguy] cool
[Blairguy] that'd be great
[bdeck2] not cool
[bdeck2] it wasted time
[Blairguy] oh
[Blairguy] well, if it worked it'd be great
[bdeck2] hey ANYTHING is possible if you are prepared to sacrifice time for it
[bdeck2] of all the pythond users
[bdeck2] only one casually requested tkinter
[bdeck2] I killed the project and archived my X11 stuff, scared someone might ask me to support it
[RadSurfer] might prove useful someday.
[bdeck2] real pythond *users* just want basic python shell scripting and socket functionality in DOS
[RadSurfer] you certainly learned alot working on it.
[RadSurfer] I rather like IDLE myself.
[bdeck2] a few play with the OpenGl stuff I went as far as releasing
[RadSurfer] it makes recalling previous lines easier.
[bdeck2] but I never get new demos, contributions to the code, or even comments
[RadSurfer] pythonwin, if you want win32 extensions and debugging.
[RadSurfer] actually... if the lines were number of something, you;d think we could recall previous lines or somehow
[bdeck2] those gooey environments are good for learning anyway
[RadSurfer] thats my only pet peeve with dos
[bdeck2] PythonD is just a basic python port that works(for the most part) in DOS
[RadSurfer] installing a tsr scroll-back buffer with copy/paste, is handy :)
[bdeck2] please no more TSRs
[bdeck2] my users already need LFN
[RadSurfer] whether or not thats compatible with pythond, I have not tested.
[bdeck2] Packet
[bdeck2] maybe something else
[bdeck2] mouse?
[bdeck2] video
[RadSurfer] video?
[bdeck2] and their own CDrom stuff
[RadSurfer] plot-graphics... like scipy ?
[bdeck2] they might have some specioal DOS video driver
[bdeck2] I was just thinking about TSRs
[RadSurfer] python with its own scroll-back buffer and recall would be nice.
[bdeck2] someone once suggested a /dev/random TSR available for DOS to improve the security in my GPG port
[bdeck2] I refuse to make these packages deppendent on more TSRs than absolutely neccessary
[RadSurfer] of course.
[bdeck2] TSR-hell was worse than DLL-hell
[RadSurfer] but if it were built-in... since the djgpp port is already kinda unique.
[bdeck2] I guess that could be done. Want to do it?
[RadSurfer] Oh! I got it!
[RadSurfer] I love swig. I use Swig with Python 2.3, and 2.4
[RadSurfer] how about a DJGPP port of Swig !!
[bdeck2] already did it
[RadSurfer] where?
[RadSurfer] gimme! GIMME!
[bdeck2] I don't support it
[bdeck2] I just use it
[RadSurfer] ok. fine. GIMME!
[RadSurfer] :-)
[bdeck2] terms of GPL ARE:
[bdeck2] must release source with binary release of any port
[RadSurfer] THAT I would test and get back to you on.
[bdeck2] just too much hassel
[RadSurfer] I'll except the binary.
[RadSurfer] Let me test it a litt.e
[RadSurfer] s/litt.e/little
[bdeck2] I already use it a lot
[bdeck2] I know it works
[RadSurfer] How..do..I..get..it.
[Blairguy] [mcericicq] how about just using reactos or linux?
[RadSurfer] which version of Swig is this based on ?
[bdeck2] SWIG Version 1.3.21
[bdeck2] Copyright (c) 1995-1998
[bdeck2] University of Utah and the Regents of the University of California
[bdeck2] Copyright (c) 1998-2003
[bdeck2] University of Chicago
[bdeck2] Compiled with gpp.exe [i686-pc-msdosdjgpp]
[RadSurfer] I'm using the latest version with python.org's 2.3, 2.4.2
[RadSurfer] sounds about right.
[Blairguy] hey ben
[RadSurfer] How big is the Binary?
[bdeck2] grrrrr....
[bdeck2] www.swig.org
[Blairguy] is pythond optimized for just 386?
[bdeck2] oh
[bdeck2] hmmmmm
[bdeck2] yeah
[bdeck2] think so
[Blairguy] that's good
[Blairguy] I have a 386
[RadSurfer] did you have to tweak it to work with PythonD ? swig source
[bdeck2] I modified the stack space to 2Meg using stubedit
[bdeck2] pythond
[bdeck2] I mean
[bdeck2] No not really
[bdeck2] maybe incidentals but porting swig isn't rocket science
[RadSurfer] if u say so.
[bdeck2] just make sure the os stuff is right... directory and path deliminators
[bdeck2] autoconf
[bdeck2] configure
[bdeck2] make
[bdeck2] make install
[bdeck2] ;-)
[RadSurfer] ok.
[Blairguy] any other interesting DJGPP ports?
[bdeck2] Some black-porting-magic: I use the following configure command line if it helps:
[RadSurfer] I may be getting busy around here, and not able to check in as often as I'd like.
[bdeck2] ./configure msdos-i386 --with-static --disable-shared --program-suffix=.exe --prefix=/dev/env/DJDIR --without-pic --bindir=/dev/env/DJDIR/bin --datadir=/dev/env/DJDIR/ --includedir=/dev/env/DJDIR/include --mandir=/dev/env/DJDIR/man --infodir=/dev/env/DJDIR/info --sysconfdir=/dev/env/DJDIR/etc --enable-networking --with-history --with-spooldir=/dev/env/DJDIR/var --disable-libtool-lock --with-pid-dir=/dev/env/DJDIR/var --with-cxx=gpp --with-exec-sh
[bdeck2] ell=bash.exe --disable-largefile --disable-gcc-pipe --enable-tcap-names --without-debug --with-fallbacks=ansi,ansi.sys,ansi80x30,dumb,wyse350,xterm,crt,gnome,vt200,cygwin,djgpp,djgpp204 --without-ada --program-suffix=.exe --without-x --enable-getcap --enable-termcap --enable-warnings --with-termpath=/dev/env/DJDIR/etc/termcap --with-md5-passwords --with-pid-dir=/dev/env/DJDIR/varq --disable-dev-random --disable-shared-handles --disable-dependenc
[bdeck2] y-tracking --disable-libtool-lock --disable-nls --disable-dependency-tracking --disable-largfile
[Blairguy] wow
[Blairguy] command.com couldn't handle that ever :-)
[RadSurfer] hehe
[bdeck2] the djgpp guys weren't as enthused
[RadSurfer] thats why god creates make files ;-)
[bdeck2] some fealt that some of the arguments were unecessary
[bdeck2] one longtimer said ./configure should be enough
[Blairguy] I personally use:
[bdeck2] the configure script should be ported if it didn't
[bdeck2] like hell!
[Blairguy] ./configure --prefix=/dev/env/DJDIR --disable-nls --disable-dependency-tracking
[Blairguy] and sometimes with:
[bdeck2] I will not port every darn configure script that assumes I should have a /var or dynamic gcc linking
[Blairguy] --host=i386-pc-msdosdjgpp --target=i386-pc-msdosdjgpp --build=i386-pc-msdosdjgpp
[bdeck2] yeah
[Blairguy] btw, how did you port ncurses?
[Blairguy] I had a lot of difficulty getting that to compile, and when it finally did, I got linking errors trying to link a prog with it
[bdeck2] http://dickey.his.com/ncurses/
[Blairguy] the ./configure script never really worked for me
[bdeck2] yeah
[bdeck2] I had to tweak the makefile
[bdeck2] that one takes a bit of patience
[Blairguy] I'm not great with makefiles
[Blairguy] or with configure scripts
[bdeck2] but it's worth it
[Blairguy] can you please send me a source tree?
[bdeck2] I didn't keep it.
[bdeck2] I just have 5.4 binaries


By the way, for those interested in antiquities, the results of this and related work are kept on sourceforge as part of the uDOS project.