Thứ Bảy, 14 tháng 6, 2008

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.

Không có nhận xét nào:

Đăng nhận xét