Mail Archives: djgpp/2009/01/12/03:45:05
> > The stub is 16-bit,
> You could unstub...
> > and the C lib does call BIOS and MS-DOS interrupts
> ... but you can't fix that easily.
> > I don't know how to combine a DJGPP + Win32 .EXE, though. Anyways, for
> > building on Windows I would suggest Cygwin (unless your app must be
> > closed src, which I think Cygwin forbids by default), esp. since you
> > can also optionally get the MinGW runtime support so you can compile
> > for either (and Cygwin uses its own .DLL and doesn't use buggy MSVCRT
> > but is *allegedly* slower). Cygwin has lots of ports of stuff, so you
> > can't really go wrong there (right, DJ?). ;-)
>
> Yeah, DJGPP is "dying"... Like, the other day, I needed to assemble and
> disassemble some 64-bit GAS code to reply to a newsgroup post, but 64-bit
> code was disabled in DJGPP's binutils. Since I don't have a Linux box here
> with 64-bit GAS, the guy didn't get a reply from me... So, I'd like to see
> some "new" and "non-DOS" features enabled in DJGPP, even if they can't be
> used for DOS, or by anyone yet due to bugs or incompletenees, etc. ELF
> support in binutils and an ELF target, perhaps "i386-elf" or
> "i386-generic-ELF", would help OS developers who are using DJGPP. Of
> course, I'd expect code produced for the ELF target to be pure 32-bit or
> 64-bit, even if non-functional... I'd prefer that the split memory model,
> i.e., application address space and below 1Mb, be kept. At some point, I'd
> like to see the standard GLIBC used for DJGPP. This would require much of
> DJGPP's POSIX and LFN related libc code patched "underneath" GLIBC. This
> would improve software compatibility, reduce porting issues, keep GNU
> utilities current, etc., although it'd eliminate much of "DJGPP" itself. If
> a suitable compile target is available, this "compatibility layer" might be
> doable entirely in the DOS DPMI host and/or 16-bit .exe stub, allowing use
> of completely stock GLIBC.
I would really like to see a gcc compiler for the windows platform.
Windows has a POSIX subsystem. I would like something that doesn't
make me use a DLL like cygwin. Besides, cygwin has dll versioning
problems. I want monolithic executeables.
I would also like to see a name change for the pdcurses library. The
name should be something more like what it does, like cursorxy, which
happens to fit in 8 characters.
Jim Michaels
- Raw text -