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