Mail Archives: djgpp/2012/05/19/08:45:09
"Rugxulo" <rugxulo AT gmail DOT com> wrote in message
news:f2041f3a-3eb3-4fbe-afc1-c4245314b211 AT r3g2000yqh DOT googlegroups DOT com...
> On May 18, 8:57 pm, "Rod Pemberton" <do_not_h DOT DOT DOT AT notemailntt DOT cmm>
> wrote:
...
> > DJGPP produces an 32-bit executable in COFF and then stubs it with a
> > 16-bit stub. So, the 32-bit executable should be able to run in whatever
> > "console" window is still available in Windows with a working loader
> > (COFF) or the correct executable format (PE ... ?).
>
> No. The BIOS and DOS APIs, not to mention DPMI, are required. I know
> you already know this. But Win64 lacks all of those. [...]
I was glossing over it ... DJGPP needs a purpose.
I was noting that DJGPP could move on from DOS to Windows "console"-only
applications. It would give the DJGPP project some purpose. The Windows
"console" still appears to be a useful platform for CLI programs on Windows.
"Console" applications aren't DOS, but that's where many DJGPP users are
currently using DJGPP. I think the developer's here know that. It would
require a rewrite of the custom DOS C library DJGPP uses, which could
possibly be huge or not. Or, it could require GLIBC etc to be ported to
Win32 or whatever WinXP or Win7 is using ... Starting with a clean copy of
GLIBC and porting it to Windows might be easier to do. It's possible that
it's been done already. I'd assume that Cygwin uses a GLIBC port, but I'm
too tired to check right now. The last three times I tried Cygwin, it had a
monstrous installer that had to use Windows, etc. So, a GCC compiler for
Windows "console" applications using zip package(s) like DJGPP would be
nice.
The other option, AISI, is for GLIBC to be ported to DOS using code from
DJGPP's custom C library to fill in the gaps or create a posix layer or do
whatever is required. Yes, I'm aware a few here said that can't be done or
is too much work.
It just seems that all the pieces and parts, software-wise, have shown
themselves for a 32-bit DOS or a Linux on DOS: Linux UMSDOS for full POSIX
file system support on FAT, Linux vm86() for v86, LRMI for BIOS calls, Linux
VFAT, ELF loaders as part of Linux or by Chris Giese (MBLOAD) and Daniel
Borca (DJELF) and Josh Vanderhoof (cross-elf), .com loader by Fabrice
Bellard (runcom.c with JS/Linux), and UMLWin32, etc. If Linux can be ported
to Javascript (JS/Linux) and Windows (UMLWin32), I don't see why
not for DOS...
That's not mentioning DOSBOX and DOSEMU. Both of which seem to have nearly
everything. You'd be surprised at the list of stuff DOSEMU supports. You'd
think I was describing DOSBOX. DOSEMU supports: LFNs, DPMI both 16-bit and
32-bit, EMS, XMS, CDROMs, v86, VGA emulation, VESA, LFBs, DOS APIs, etc. If
that's correct, it's a "Windows console" (or roughly a "32-bit DOS"), but
for Linux. If DOSEMU could be made to work with a DOS port of UMLWin32 or
JS/Linux, ...
> Apparently (almost) nobody besides us wants to keep DOS apps alive.
If a DJGPP program is purely ANSI/ISO C code, not explicitly calling DPMI or
using assembly etc, then it should recompile for GCC, e.g., Linux or Cygwin.
Only a modest percentage of my programs explicitly use DPMI, and that could
be backed out.
Well, I don't specifically need DOS. I like DOS. I want a CLI and 32-bit
(or 64-bit) C compiler. I like CLIs, of which I prefer DOS to Linux. I
like simple, reliable OSes. I'm not too fond of Linux. Although, once
you're installed, setup, and in a GUI, everything is acceptable. I.e., as
long as you don't stay in the bootup CLI which I prefer, Linux is "o.k." It
has a list of issues, IMO. Windows "console" windows and Linux term
windows, are acceptable if true CLIs are unavailable. And, I need an
up-to-date GUI based OS for decent internet browsing. So, once Win98/SE is
no longer supported by KernelEx, I'll probably be moving on to Linux.
Rod Pemberton
- Raw text -