#Progesoft progecad driver#
#Progesoft progecad windows#

Some black-porting-magic: I use the following configure command line if it helps: maybe incidentals but porting swig isn't rocket science I modified the stack space to 2Meg using stubedit did you have to tweak it to work with PythonD ? swig source I'm using the latest version with 's 2.3, 2.4.2 University of Utah and the Regents of the University of California which version of Swig is this based on ? THAT I would test and get back to you on.

must release source with binary release of any port since the djgpp port is already kinda unique. I refuse to make these packages deppendent on more TSRs than absolutely neccessary someone once suggested a /dev/random TSR available for DOS to improve the security in my GPG port python with its own scroll-back buffer and recall would be nice.

#Progesoft progecad driver#

they might have some specioal DOS video driver whether or not thats compatible with pythond, I have not tested. installing a tsr scroll-back buffer with copy/paste, is handy :) PythonD is just a basic python port that works(for the most part) in DOS those gooey environments are good for learning anyway if the lines were number of something, you d think we could recall previous lines or somehow pythonwin, if you want win32 extensions and debugging. but I never get new demos, contributions to the code, or even comments it makes recalling previous lines easier. a few play with the OpenGl stuff I went as far as releasing you certainly learned alot working on it. real pythond *users* just want basic python shell scripting and socket functionality in DOS I killed the project and archived my X11 stuff, scared someone might ask me to support it hey ANYTHING is possible if you are prepared to sacrifice time for it which I fooled with once, go as far as having a white screen up, but that is as far as that went for something like the X11 ghostscript driver but the true client-server multitasking window-manager you think of with X11 simply isn't there. so have you done any other exotic ports? but under the hood, it is *anything* but X11 it is, for arguments sake, a DOS windowing environemnt that very much looks like the old days of sunOS 1.x my DJGPP-X11 is *NOT* a client-server app so what about WATT-32 for the socket layer? the shell is called in a fork and signalled remotely using. but that's simply the point where it would stop being DOS and start being UNIX the terminal provides a text environment for a shell They were all multitasking socket oriented terminals. couldn't find any simple enough to port just using fvwm and djgpp functionality.

#Progesoft progecad windows#

anyways, I wonder if windows got its start like this? that was the problem I was trying to describe GEM is a 16-bit DOS GUI that has lots of progs written for it well, if you want that then you can use SEAL2 or OzoneGUI be really cool if it got itself worked directly into a DOS-OS kernel could it actually display the graphics on DOS? nobody had any real time to make a further go of it. If others picked up and worked with it.I wonder. I realized my X11 port was hardly a port at all or invent a hotkey that toggled between the two with some degree of stability 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 I realized that I would have to write custom DJGPP-FVWM wrappers around the window applets. without requiring some third-party app like desqviewx or something The Port includes a version of the FVWM windowing manager The guy doing Kaffe-PC updated the mouse driver for GRX2 The DJGPP X11 port was still based on GRX1 IO using the old DJGPP V1 IO queue The mouse IO no longer worked because things moved on to GRX2 that meant whiping away the coderot from the DJGPP X11 port The original plan ages ago was to port tkinter A pasted IRC chat from the defunct #djgpp channel tells the story: Another of these projects was a (yet another) failed attempt to port a functional X11 GUI framework to the same environment. One of those is PythonD, a complete port of the python scripting language to the 32-bit DJGPP development platform for DOS. Many readers are unaware that CADDIT also participates in various splinter OSD projects.