Mail Archives: djgpp/2009/01/06/15:31:27
"Rugxulo" <rugxulo AT gmail DOT com> wrote in message
news:9941ccce-87a6-4ace-9f78-9b15710643bd AT x8g2000yqk DOT googlegroups DOT com...
On Jan 3, 1:24 pm, Eli Zaretskii <e DOT DOT DOT AT gnu DOT org> wrote:
> > From: blueice <biject DOT b DOT DOT DOT AT gmail DOT com>
> > Date: Sat, 3 Jan 2009 10:45:57 -0800 (PST)
>
> > > > I have used DJGPP for years. The problem is this my executable does
> > > > not run on a VISTA 64 bit machine.
>
Well, another good post Rugxulo.
> The latest
> DOSEMU for GNU/Linux emulates the 16-bit stuff under 64-bit mode,
I think the best solution would be DOSEMU ported to Vista, using FreeDOS as
the required DOS. IIRC, the latest DOSEMU builds using libSDL, so I'd think
this is doable, if not already done...
> 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. There is some history to support that this is
possible, see the MOSS DPMI host:
http://www.cs.utah.edu/flux/moss/moss.html
Since it seems MOSS uses an *almost* stock GCC and GLIBC, I'd think a port
of MOSS to DJGPP might help in creating a complete, stock GCC and GLIBC
combination that works on DOS. I'd suggest removing any code that might
bypass DJGPP, e.g., the Flux OS toolkit code. I think MOSS might run on
other DOS DPMI hosts like CWSDPMI, so I'd probably remove VCPI, EMS, and any
unecessary DPMI, etc. code. Then, the MOSS DOS extender will compile as a
standard DJGPP application, it would then use CWSDPMI and DJGPP's POSIX and
LFN's, etc. which are probably more up to date and likely have fewer errors.
Since MOSS.EXE is 38k, the resulting "conversion layer" after coreing should
be very small, perhaps small enough that it could be added to CWSDPMI. It
seems that MOSS is using the following "primitives" or syscalls:
_exit, open, close, read, write, lseek, rename, sbrk, gettimeofday, unlink,
fstat, mlock, munlock, mmap, munmap, irq_request, irq_free, kill, sigaction,
sigprocmask, sigpending, alloc_dos, alloc_dma, mlockall, munlockall
MOSS has C wrappers to call the following DPMI functions. It doesn't use
five or so of them. Three are DPMI 1.0, but only two are used. Of the DPMI
1.0 calls, one is supported by CWSDPMI and one isn't:
1687 (2f), 0, 6, 7, 8, A, B, C, D, 202, 203, 204, 205, 300, 400, 501, 502,
504, 505, 509, 600, 601, 604
Rod Pemberton
- Raw text -