TRYING TO MAKE EXE RUN ON FRIENDS MACHINE
blueice
not
run on a VISTA 64 bit machine. Is there a way to make an executable
that
will run on his machine with DGJPP. my machine is XP I want it to run
on other machines.
Some have said to use MinGW but I don't want to replace my DJGPP
I would only use MinGW infrequently if I have to go down that path.
I am not as good as I should be on how to set up a batch file or two
that I could execute in the command mode. So that I could tempoarly
change to use MinGW and then another batch file to get back to my
standard DJGPP mode.
Thanks
Dave
Eli Zaretskii
> Date: Sat, 3 Jan 2009 07:17:14 -0800 (PST)
>
> I have used DJGPP for years. The problem is this my executable does
> not run on a VISTA 64 bit machine.
What do you mean, exactly, by "does not run"? Does it crash? exist
with some error message? silently does nothing? something else?
blueice
> > From: blueice <biject.b...@gmail.com>
It runs on my machine which is a windows XP machine I use
DJGPP GNU but the VISTA 64 machine claims it can't run because
it thinks it a 16bit application
Eli Zaretskii
> Date: Sat, 3 Jan 2009 10:45:57 -0800 (PST)
Well, it Vista 64 is documented to be unable to run 16-bit (DOS)
applications, then I guess you are out of luck: DJGPP programs _are_,
as far as Windows is concerned, 16-bit DOS executables.
As far as MinGW setup is concerned, I have on my XP machine a dual
MinGW/DJGPP setup, and it's fairly easy: all I need to switch from
MinGW to DJGPP is to run a single batch file which says just this:
@echo off
set DJGPP=d:/usr/djgpp/djgpp.env
set Path=d:\usr\djgpp\bin;%Path%
The last of these 3 lines is what does the trick, as setting the DJGPP
environment variable does nothing bad to MinGW.
Rugxulo
On Jan 3, 1:24 pm, Eli Zaretskii <e...@gnu.org> wrote:
> > From: blueice <biject.b...@gmail.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.
>
The NT series has always had DOS compatibility issues as it's not
based upon DOS like Win9x, etc. Win2k had some kind of memory bugs
which had to be worked around. Then Vista disabled full-screen and (by
default) limited DPMI memory to 32 MB. However, in this case, it's not
(directly) Microsoft's fault. AMD64 long mode doesn't allow 16-bit
programs to run at the same time as 64-bit stuff. Only the emulation
mode allows 16- and 32-bit stuff (but no 64-bit then). The latest
DOSEMU for GNU/Linux emulates the 16-bit stuff under 64-bit mode, but
so far, Microsoft hasn't written / published their own NTVDM64
(sadly).
> Well, it Vista 64 is documented to be unable to run 16-bit (DOS)
> applications, then I guess you are out of luck: DJGPP programs _are_,
> as far as Windows is concerned, 16-bit DOS executables.
The stub is 16-bit, and the C lib does call BIOS and MS-DOS interrupts
a lot, so there's not much you can do (that I'm aware of). RSXNT/DJ
(which is old / abandoned) used to create dual DOS/Win32 .EXEs. 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?). ;-)
Another option is OpenWatcom, which transparently supports both 32-bit
DOS and Windows, but its DOS support lacks much of the niceties of
DJGPP (LFNs, POSIX). You may be able to get around some of that by
trying Japheth's HX (either linking his Win32 libs statically to
your .EXE and tacking on HDPMI32 for a "special" DOS .EXE else just
letting the user run the static Win32 .EXE under HXRT emulation setup
in pure DOS).
Anyways, if none of that sounds appealing, you're stuck to just using
either DOSBox or some virtualization (e.g. VirtualBox or QEMU or
BOCHS) with FreeDOS.
P.S. Why are you running 64-bit Vista anyways? Unless you have / need
> 3 GB of RAM, I think it's overkill.
blueice
>
> P.S. Why are you running 64-bit Vista anyways? Unless you have / need
>
> > 3 GB of RAM, I think it's overkill.
>
>
I am not running 64-bit Vista. There is site that allows
one to test compression programs. They have huge files and
compare various compressors. The machine uses 64-bit Vista.
I have tried to run my compressors. Which only are only made in
DJGPP GNU. They don't run. So I wanted to compile them in
some easy way so they could run on that machine. I don't have
a clue where the other machine is physically located. But
they can't run executables made with DJGPP. Again I have
XP not VISTA.
I do have BCC55 but not sure what kind of executables
it actually makes I have only used in on short programs.
My current compressors are all experimental. I have a
great interest in writing a better BWTS compressor since
I created a bijective BWTS but its all in DGJPP GNU C++
I would like to test them with others who have an interest
in compression.
Rugxulo
On Jan 3, 10:15 pm, blueice <biject.b...@gmail.com> wrote:
> On Jan 3, 1:58 pm, Rugxulo <rugx...@gmail.com> wrote:
>
> > P.S. Why are you running 64-bit Vista anyways? Unless you have / need
>
> > > 3 GB of RAM, I think it's overkill.
>
> I am not running 64-bit Vista. There is site that allows
> one to test compression programs. They have huge files and
> compare various compressors. The machine uses 64-bit Vista.
> I have tried to run my compressors. Which only are only made in
> DJGPP GNU. They don't run. So I wanted to compile them in
> some easy way so they could run on that machine. I don't have
> a clue where the other machine is physically located. But
> they can't run executables made with DJGPP. Again I have
> XP not VISTA.
>
> I do have BCC55 but not sure what kind of executables
> it actually makes I have only used in on short programs.
I think Borland C 5.5 produces Win32 programs, which should work fine.
> My current compressors are all experimental. I have a
> great interest in writing a better BWTS compressor since
> I created a bijective BWTS but its all in DGJPP GNU C++
> I would like to test them with others who have an interest
> in compression.
Since DJGPP uses stock GCC/G++, unless you're doing something really
DOS-ish (non-ANSI), it should compile fine for other platforms with
GCC, e.g. Cygwin or MinGW.
blueice
I got Borland to run some short easy programs. But when I
tired my basic simple 256 airhtmetic compressor it coughed
all over the place. Made many changes and it never compiled.
I did download MinGW it finally compile with out errors.
But the code starts to run in command mode but fails with
a nasty windows popup. but it does run from windows except
I have no clue yet how to give the comman line parameters.
Any help wold be welcomed.
Thank You
blueice
Thanks to all here. I got it done and create the VISTA 64
bit binary with MinGW I bite the bullet and downloaded a
vista version it compiled and run on the other machine
the hard part was changing the PATH
to use MinGW
PATH=%PATH:DJGPP=MinGW%
to go back to DJGPP GCC
PATH=%PATH:MinGW=DJGPP%
Thank You
Rod Pemberton
news:9941ccce-87a6-4ace...@x8g2000yqk.googlegroups.com...
On Jan 3, 1:24 pm, Eli Zaretskii <e...@gnu.org> wrote:
> > From: blueice <biject.b...@gmail.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
Rugxulo
On Jan 6, 5:11 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> Well, another good post Rugxulo.
Let's go for 2/2. :-)
> > 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...
DOSEMU also needs S-Lang2, IIRC. But I have no idea when DOSEMU was or
ever will be compiled for Windows.
> > The stub is 16-bit,
>
> You could unstub...
Sure, but I see no advantage there.
> > and the C lib does call BIOS and MS-DOS interrupts
>
> ... but you can't fix that easily.
It can't be that hard. I mean, people write JIT compilers and VMs all
the time (e.g. Ruby or Perl).
> > 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.
Cygwin and MinGW aren't exactly perfect either, still stuck to old
versions due to .DLL and exception issues (as well as the always-
problematic lack of maintainers).
Anyways, there have been a (very) few attempts at a 64-bit DOS
extender, but they're mostly proof of concept and don't do anything
(or even return cleanly). Hence 64-bit is less interesting to DOS
users (esp. no V86 mode). But there are DOS ports of certain tools
that support it. (Good luck building a DJGPP cross-compiler for it!
GCC is kinda complex / annoying to rebuild.) At the very least are
Agner Fog's ObjConv and Nick Kurshev's BIEW, both of which have DOS
ports. I'm not aware of other 64-bit tools (besides NASM, FASM, YASM,
obviously).
> ELF support in binutils and an ELF target, perhaps "i386-elf" or
> "i386-generic-ELF", would help OS developers who are using DJGPP.
But there was a COFF bootloader at one time, right? (I know you know
more than me on this since I don't write OSes, heh.) But yeah, ELF is
pretty ubiquitous, so having some support in DJGPP can't hurt.
> 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.
It would only optionally replace it. Remember that the DJGPP/ELF third-
party experimental hack kept both COFF and ELF support. (And boy, -
static ELF is much bigger than COFF, sheesh. WTF?!)
> 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
= "Mach on DOS" (Bryan Ford)
= GPL, compiles fully with GPL tools, uses subset of FreeBSD libs so
free for almost any use
= not updated since 1996
= (old) Linux binaries (GCC 2.7.2) are dynamically linked (doh), don't
run on Slackware 11
= no real-world examples anywhere (or at least I couldn't find 'em)
= currently no (obvious, automatic) way to bind .EXE and a.out ELF
file into one (although possible)
= GCC 3.3 (and similar timeframe BinUtils) still had (leftover)
support for it, but I dunno after that
> 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
MOSS might be too minimal for GLIBC, and some things are pretty hard
to port. Or at least, people with the *nix mindset have a hard time
(apparently), even if they are willing (which they usually
aren't). :-/ I've heard it said that DOS is only viable for
games, but nobody seems to be writing many of those anymore. Maybe
just a subset of GLIBC would prove worthwhile, but I'm not
qualified. :-(
> 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.
Assuming you want to recompile all of that "POSIX and LFN's" for ELF
(which will break a few things, e.g. unexec).
> 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.
MOSS.EXE is limited to 64k (although they claim they knew how to
overcome it but never mentioned, only pointed to now-nonexisting
mailing list), so 38k + 20k for CWSDPMI = pretty close to the limit
(tight assembly probably needed).
> It seems that MOSS is using the following "primitives" or syscalls:
It would be interesting to see an actual app running via MOSS, but
that requires rebuilding the toolset (which I failed at doing last
night, blech). At least MOSS.EXE comes precompiled, but it didn't like
the ELF .o that DJGPP/ELF made, so ....
> 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:
Although I think they should speak for themselves, I heavily suspect
CWS is too busy / disinterested. Same for DJ. There aren't a lot of
qualified DPMI authors anymore.
> 1687 (2f), 0, 6, 7, 8, A, B, C, D, 202, 203, 204, 205, 300, 400, 501, 502,
> 504, 505, 509, 600, 601, 604
You know way more about DPMI than I do, so surely you know how hard it
is. ;-)
Rugxulo
On Jan 7, 10:53 am, Rugxulo <rugx...@gmail.com> wrote:
> Hi,
>
> On Jan 6, 5:11 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>
> > Well, another good post Rugxulo.
>
> Let's go for 2/2. :-)
Let's go 3/3. :-))
> > ELF support in binutils and an ELF target, perhaps "i386-elf" or
> > "i386-generic-ELF", would help OS developers who are using DJGPP.
I found a few links here (http://geezer.osdevbrasil.net/os/index.htm)
that can boot from COFF or ELF, so it looks like either is fine. (I
have no idea if one is easier or better, your turn to supply reasons
for one or the other.)
> But yeah, ELF is pretty ubiquitous, so having some support in DJGPP can't hurt.
Lots of debates in the c.o.m.d archives (BFD is GPL, DJGPP is BSD-ish)
as well as whining about leading underscores and object conversions
and changing all assembly files (which ObjConv can now fix anyways).
Heck, I even found one mention (in the middle of an ELF discussion
from 1996) that mentions MOSS. Too bad it didn't get publicized more,
I guess. (Nobody picked up on using it.)
Okay, now I found one post: Orlando Andico says it doesn't handle
DPMI (although I think it claims to, just buggy) and that the "libc
sucks", which isn't true, but his failure in compiling Sox turned him
against it. It can't be that bad 'cause it's 400k !!
James Soutter claims his MOSS app dumped core / didn't run properly
and had '\n' -> '\r\n' issues.
Nothing else except one guy saying he barely "knew about it" but
didn't test it.
Well, only 13 years later, but at least someone has publicly tested it
now!! :-))
> > 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
>
> = "Mach on DOS" (Bryan Ford)
> = GPL, compiles fully with GPL tools, uses subset of FreeBSD libs so
> free for almost any use
> = not updated since 1996
> = (old) Linux binaries (GCC 2.7.2) are dynamically linked (doh), don't
> run on Slackware 11
I found two old Linuxes that support libc5:
* tomsrtbt (which VirtualBox hates, quite unstable there ... plus
doesn't have any room anyways, you can't unpack to /usr/local ... at
least, I'm too dumb to know how)
* BasicLinux (small 20 MB UMSDOS distro, this is preferred IMHO ...
if you want Linux without rebuilding)
http://www.volny.cz/basiclinux/
> = no real-world examples anywhere (or at least I couldn't find 'em)
Well, it's not the first, but it's the first public example I know
about!
http://rugxulo.googlepages.com/moss-7z.zip (72k)
That is Igor Pavlov's simple ANSI C 7-Zip decoder from LZMA SDK 4.63
(now "public domain") with srcs (in .7z, heh) and MOSS.EXE plus A.OUT
(ELF compilation) plus my own stupid MAKE.BAT. It doesn't seem to run
in Vista (surprise surprise) but DOSBox 0.72 works fine. FreeDOS
(under QEMU or VirtualBox) only likes it when using either no memory
managers or FDXMS (i.e. JEMM386 crashes, HIMEMX "can't disable A20").
I recompiled (fairly old but hopefully simpler) GCC 2.95.3 and
BinUtils 2.10.1 via DJGPP to use DJGPP host and MOSS target. It works,
but I really really really *really* don't understand where / what /
how to put the --prefix or configure or whatever so that everything
works like DJGPP.
In other words, how the hell do I get it to use normal subdirs (e.g. /
lib/) like in DJGPP without having to manually copy crt*.o to current
dir and use -I- -I/include -L/lib etc. etc. (I know I'm doing it
wrong, and someone must know how to fix this.) DJ?? Andris??
Note that I did not recompile MOSS.EXE itself, only GCC and BinUtils
(this was before I tried antiX Linux and tomsrtbt and BasicLinux to
use the pre-compiled, dynamically-linked old GCC 2.7.2 binaries from
1996), and it had MOSS support "built-in", so I didn't have to patch
anything. I ended up just using my DOS compiler instead of the
original, which I assume is okay (I mean, it works AFAICT).
Ideally, I would actually like to sort out the dir structure / "search
path" problem and then package it up officially just so others can see
it, try it, use it, look at it, study it, improve it, etc. Cross-
compiling from Linux is cool, but why not from DOS itself too? ;-)
Supposedly, I don't have to provide sources unless I modify MOSS.EXE
itself, so I'm not doing so. (It's not that I'm unwilling, just
running low on free space on my homepage. Okay, not that low but
pretty darn close, < 5 MB free.)
> = currently no (obvious, automatic) way to bind .EXE and a.out ELF
> file into one (although possible)
As you probably know, WDOSX always does this and supports adding files
too, but files are not *automatically* read from the main .EXE due to
needing a special API (i.e. you'd have to wrap DJGPP C calls manually,
I think). And Veit K. had some assembly stub that let you use WDOSX
externally (without adding it to every freakin' .EXE). Of course, this
is moot for us (PMODE/DJ, CWSDPMI, DPMIONE, NTVDM, etc).
> = GCC 3.3 (and similar timeframe BinUtils) still had (leftover)
> support for it, but I dunno after that
As mentioned, I decided to try 2.95.3 since that was "old enough" to
probably work as well as being "simpler" to recompile. Same with
BinUtils 2.10.1. I think I had to switch back to GCC 3.4.4 to compile
AS.EXE, though, as it whined otherwise.
> > 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
Bryan Ford just used stuff from FreeBSD and the Flux OS Toolkit. Not
sure how much he left out.
> > 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.
I personally would like if somebody actually got the MOSS.EXE extender
to compile these days (after porting to DOS "host", of course). Then
it could be modified much easier. Also, binding to .EXE and/or adding
files to .EXE would be nice to figure out and automate. (Doubt Bryan
is interested assuming I can find him, but who knows??)
> > 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.
I forgot that you intended to strip some stuff, so it will be much
smaller. (D3X is another pretty small stub DPMI server / DOS extender
and uses NASM and DJGPP to build, plus it has the same author as DJGPP/
ELF although D3X only accepts COFF or Watcom LE, a la WDOSX).
> > 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:
Strange that he supported any DPMI 1.0 at all. I wonder how well it
works under Win 3.x or Win9x.
> Although I think they should speak for themselves, I heavily suspect
> CWS is too busy / disinterested. Same for DJ. There aren't a lot of
> qualified DPMI authors anymore.
All the really talented guys are just too busy. So you're stuck with
shrimps like me. :-)
> > 1687 (2f), 0, 6, 7, 8, A, B, C, D, 202, 203, 204, 205, 300, 400, 501, 502,
> > 504, 505, 509, 600, 601, 604
>
> You know way more about DPMI than I do, so surely you know how hard it
> is. ;-)
"Written almost entirely in C", so at least that makes things easy to
port.
Please tell me your thoughts! :-)
Sébastien WILLEMIJNS
news:gjve0m$2rt$1...@news.tornevall.net:
> echo echo %%* > %TEMP%\deleteme.bat
yep, thanks it works well... the trouble is i can not use "%%2 %%3 %%4 or
more parameter" with this hack but never mind...
Rod Pemberton
> Please tell me your thoughts! :-)
Glad to hear it works! I'll try the a.out you created after I get some
food. I had one in-progress big post to the 2/2... No point now. Maybe
later on today or tomorrow..., I'll try to recreate what you did and see
were that leads me. If I can compile it, it should be easier to port or at
least get the code to compile on newer versions. I'm not saying I can get
it working or anything, just that I'll look into it.
> All the really talented guys are just too busy. So you're stuck with
shrimps like me. :-)
Well, I may be asking you some questions about cross-compiling, how you
setup your compile environment, etc...
Rod Pemberton
Rod Pemberton
> Well, it's not the first, but it's the first public example I know
> about!
>
> http://rugxulo.googlepages.com/moss-7z.zip (72k)
>
> That is Igor Pavlov's simple ANSI C 7-Zip decoder from LZMA SDK 4.63
> (now "public domain") with srcs (in .7z, heh) and MOSS.EXE plus A.OUT
> (ELF compilation) plus my own stupid MAKE.BAT. It doesn't seem to run
> in Vista (surprise surprise) but DOSBox 0.72 works fine. FreeDOS
> (under QEMU or VirtualBox) only likes it when using either no memory
> managers or FDXMS (i.e. JEMM386 crashes, HIMEMX "can't disable A20").
The MOSS version runs under MS-DOS v7.10, but has "'\n' -> '\r\n' issues."
Runs in Win98SE dosbox or console, but complains repeatedly about a memory
allocation problem prior to running with CRLF issues... (Thanks putting a
.7z file in the zip, BTW.)
Rod Pemberton
Rugxulo
On Jan 8, 9:09 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:0541cc98-689c-4e6c...@l37g2000vba.googlegroups.com...
>
> > Please tell me your thoughts! :-)
>
> Glad to hear it works! I'll try the a.out you created after I get some
> food. I had one in-progress big post to the 2/2... No point now. Maybe
> later on today or tomorrow..., I'll try to recreate what you did and see
> were that leads me.
The only problem I had is due to inexperience: I don't know how to
organize the actual compiler install to correctly work without -I and -
L hacks (i.e. I didn't want to make a C:\USR\LOCAL dir just to hope
it'd work). I mean, I'm wondering can you install it similar to a
default DJGPP install (C:\DJGPP\BIN, LIB, INCLUDE, etc.) or do you
have to run it like "..\i386-moss\i386-moss-gcc" ?? I'm sure somebody
knows, they're probably just too lazy^H^H^H^H busy. ;-)
Anyways, I could always just e-mail you the binaries I compiled
(although I'm unsure how to handle "giving you" the srcs, which I
didn't modify ... stupid low website disk space). Or you could just
use BasicLinux (be sure to put it in C:\BASLIN) with the old GCC 2.7.2
pre-compiled binaries from the FTP site. Heck, FreeDOS disk image +
BasicLinux + MOSS Linux GCC cross compiler is probably not a huge
download, even for dialup.
> If I can compile it, it should be easier to port or at
> least get the code to compile on newer versions. I'm not saying I can get
> it working or anything, just that I'll look into it.
I know, no pressure. It was all your idea anyways. Only try to have
some fun with it. ;-)
> > All the really talented guys are just too busy. So you're stuck with shrimps like me. :-)
>
> Well, I may be asking you some questions about cross-compiling, how you
> setup your compile environment, etc...
You can ask, but I'm probably one of the last to know anything about
that. :-))
> > http://rugxulo.googlepages.com/moss-7z.zip (72k)
> >
> > That is Igor Pavlov's simple ANSI C 7-Zip decoder from LZMA SDK 4.63
> > (now "public domain") with srcs (in .7z, heh) and MOSS.EXE plus A.OUT
> > (ELF compilation) plus my own stupid MAKE.BAT. It doesn't seem to run
> > in Vista (surprise surprise) but DOSBox 0.72 works fine. FreeDOS
> > (under QEMU or VirtualBox) only likes it when using either no memory
> > managers or FDXMS (i.e. JEMM386 crashes, HIMEMX "can't disable A20").
>
> The MOSS version runs under MS-DOS v7.10, but has "'\n' -> '\r\n' issues."
I have no idea what that means. I'll have to test on some real DOS
boxes later today or so.
> Runs in Win98SE dosbox or console, but complains repeatedly about a memory
> allocation problem prior to running with CRLF issues... (Thanks putting a
> .7z file in the zip, BTW.)
It might need a .PIF or even EMS (see below), but that's only based on
what I read about the following app:
P.S. Just to keep this going, here's some more info (useful and fun,
what a concept!):
I found an actual example using MOSS, and it's by the same guy (Bryan
Ford): Inner Worlds (now freeware)
http://www.sleepless.com/iw/
http://www.mobygames.com/game/dos/inner-worlds
http://www.dosbox.com/comp_list.php?showID=2493&letter=I
http://www.dosgames.com/g_side3.php
It's fairly big for a DOS game (20 MB once installed, same size as
BasicLinux, heh), most of that is data anyways, but it's pretty cool
(to say the least). The funny part is that the custom installer uses
MOSS, the SETUP and README progs use MOSS, and so does the actual game
itself (IW.EXE), which is 17 MB with all data and extender bound to
itself. Now that's a whopper! ;-)
total 17207
-rw-r--r-- 1 Rugxulo dos 72964 Jan 8 02:42 iw-m1.sav
-rw-r--r-- 1 Rugxulo dos 98276 Jan 8 03:21 iw-m2.sav
-rw-r--r-- 1 Rugxulo dos 310 Jan 7 21:59 iw.cfg
-rwxr-xr-x 1 Rugxulo dos 17150464 Jan 7 21:58 iw.exe
-rwxr-xr-x 1 Rugxulo dos 2623 Jan 7 21:58 iw.icl
-rw-r--r-- 1 Rugxulo dos 5540 Jan 8 03:21 iw.sav
-rw-r--r-- 1 Rugxulo dos 1645 Jan 7 21:58 order.txt
-rwxr-xr-x 1 Rugxulo dos 133120 Jan 7 21:58 readme.exe
-rw-r--r-- 1 Rugxulo dos 19778 Jan 7 21:58 readme.txt
-rwxr-xr-x 1 Rugxulo dos 133120 Jan 7 21:58 setup.exe
It actually reminds me of _Shadow of the Beast_ for Atari Lynx. It's
dated from 1996, needs 486 + VGA + 8 MB RAM (e.g. DOSBox 0.72 works
fine on my machine). I should test on real hardware (luckily I have a
486 !), but I'm skeptical that it may want an FPU (doh). Why else
require a 486, bswap?? (heh)
Here's some more (vaguely related) links that may also prove
interesting:
http://en.wikipedia.org/wiki/Mach_kernel#The_Next_Generation
http://pdos.csail.mit.edu/~baford/vm/
http://www.brynosaurus.com/
Hope this helps! And don't forget to have fun! :-)
P.P.S. Sébastien, you cross-posted to the wrong group! :-P
Rod Pemberton
> The only problem I had is due to inexperience: I don't know how to
> organize the actual compiler install to correctly work without -I and -
> L hacks (i.e. I didn't want to make a C:\USR\LOCAL dir just to hope
> it'd work). I mean, I'm wondering can you install it similar to a
> default DJGPP install (C:\DJGPP\BIN, LIB, INCLUDE, etc.) or do you
> have to run it like "..\i386-moss\i386-moss-gcc" ?? I'm sure somebody
> knows, they're probably just too lazy^H^H^H^H busy. ;-)
It seems Binutils 2.19 supports moss as does GCC upto 3.3.6. So, you should
be able to build new enough versions to be useful.
But, I'm having problems. Neither DJGPP 3.4.1 nor 3.3.6 would cross-compile
stock GCC 3.3.6 failing in the middle of compiling gcc.c complaining about
an
assignments to a read-only variable. Perhaps, I should try DJGPP GCC 3.3.6
compiling DJGPP GCC 3.3.6 as a cross-compile, but I thought the code for GCC
hadn't been changed for DJGPP... Binutils fails near the end of make with
error 2. I know from past experience, that once everything is working
correctly, those mysteriously go away. This is one reason why I prefer to
always have binaries, but be able to get source instead of the GNU it's
always source, and never binaries model. Even if the code won't compile
anymore, the executable will work.
> Anyways, I could always just e-mail you the binaries I compiled
I'd rather get it to work on my machine. I've experienced similar problems
trying to cross-build with DJGPP in the past.
> > If I can compile it, it should be easier to port or at
> > least get the code to compile on newer versions. I'm not saying I can
get
> > it working or anything, just that I'll look into it.
>
> I know, no pressure. It was all your idea anyways. Only try to have
> some fun with it. ;-)
Sorry, for some reason, I was thinking you compiled moss.exe... Actually,
with the size of moss.exe being so small, I can't imagine all of the code he
included actually being used. It's just a matter of determining what was
used, since I'm not sure that it'll ever compile again in it's current form.
> You can ask
./configure --target=i386-moss
./configure --target=i386-moss --host=i386-pc-msdosdjgpp --build=i386-pc-msd
osdjgpp
What did you use or do? But, I think I might be using the wrong set of
sources: stock GNU instead of DJGPP.
> > The MOSS version runs under MS-DOS v7.10, but has "'\n' -> '\r\n'
issues."
>
> I have no idea what that means.
Ah, I quoted what you quoted. DOS uses both an ASCII carriage return (CR or
\r) and linefeed (LF or \n) to move to the beginning of the next line. LF
in DOS moves down a line. CR moves to the begining of the line. *NIX
usually uses just LF to do both. Mac's use just CR to do both. This was a
historical misunderstanding with early ASCII. DJGPP fixes this behind the
scenes. So, when text just using LF is displayed, it moves down a line, but
not to the start of the line. The text shows up as a staggered and
wrap-around look. Think stack of domino's versus stack of domino's with a
tilt.
> I found an actual example using MOSS, and it's by the same guy (Bryan
> Ford): Inner Worlds (now freeware)
>
> http://www.dosgames.com/g_side3.php
>
> It's fairly big for a DOS game (20 MB once installed, same size as
> BasicLinux, heh), most of that is data anyways, but it's pretty cool
> (to say the least). The funny part is that the custom installer uses
> MOSS, the SETUP and README progs use MOSS, and so does the actual game
> itself (IW.EXE), which is 17 MB with all data and extender bound to
> itself. Now that's a whopper! ;-)
...
> Atari Lynx
What? I thought you were younger than that... ;)
I didn't realize he worked on vx32 also... I've read the papers and looked
it over a few times. It, like many other open projects, has some features I
like, but it isn't as developed as much as I'd like or going in the
direction I'd like. In the case of vx32, they just do binary translation to
implement their sandbox. But, with more development, vx32 could be used as
an x86 emulator, possibly with much better performance than others.
> P.P.S. S�bastien, you cross-posted to the wrong group! :-P
I threw on comp.os.msdos.programmer. He posted to the wrong thread there.
His response was to Herbert Kleebauer in "Adding equal sign as a parameter."
RP
Rugxulo
On Jan 8, 3:24 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:886d17b9-399f-48ed...@s20g2000yqh.googlegroups.com...
>
> > The only problem I had is due to inexperience: I don't know how to
> > organize the actual compiler install to correctly work without -I and -
> > L hacks (i.e. I didn't want to make a C:\USR\LOCAL dir just to hope
> > it'd work). I mean, I'm wondering can you install it similar to a
> > default DJGPP install (C:\DJGPP\BIN, LIB, INCLUDE, etc.) or do you
> > have to run it like "..\i386-moss\i386-moss-gcc" ?? I'm sure somebody
> > knows, they're probably just too lazy^H^H^H^H busy. ;-)
>
> It seems Binutils 2.19 supports moss as does GCC upto 3.3.6. So, you should
> be able to build new enough versions to be useful.
3.4.x introduced optimizations for the Pentium4, I think. It's also
slower than 3.2.3 (which has some C99). And 2.95.3 supports PPro but
was the last of its branch (combined EGCS + GNU). And 3.0.2 etc. is
much bigger in size and slower. (2.96 was an unofficial patch by Red
Hat.) As you know, 2.8.1 was the first official GNU version to support
586 optimizations (since 2.7.2.1 was 486 only). Okay, enough history
lesson! :-)
I don't know what changes between releases of Binutils. Reading the
changelog a while back was unimpressive. At least for us (DOS / COFF)
I don't think anything has changed in a while. And I'm not using MMX
or SSE for this or rebuilding latest GCC, so I'm less interested in
newest. (Those probably take a lot longer to compile, too.) For this I
just used stock BinUtils srcs 2.10.1 from GNU since I don't think DJ
archives all old versions (e.g. no srcs for older than 2.15 in either /
current/ or /beta/).
EDIT: Actually, DJ's ftp seems to have older in /deleted/ (e.g. bnu27
[bs], bnu2951[bs], etc). bnu2951.README says MMX, SSE, and 3dnow! are
supported (and, surprisingly, claims to not need LFN environment to
compile).
In any case, I wanted something lean, small, and fast as well as old
enough to hopefully work but new enough to be useful. It's not that I
need Pentium-specific optimizations, but too old means new code won't
work (and vice versa). Oh, BTW, when was it that ".intel_syntax" was
added, 2.9? That is indeed worth having. :-)) This also means
the little assembly MOSS uses is AT&T (yuck).
OFFTOPIC: For instance, I recompiled GCC 2.95.3 and BinUtils 2.16.1
via "-Os" recently with the goal of producing a small 2.03p2-based
compiler that would fit on a floppy compressed. Anything older is too
moldy for my tastes, and anything newer is too big to fit. (7zdec
compiled by OpenWatcom comes in handy here. I have not yet released
the .7z on my site, though, still barely tweaking it, but it's done
and unpacks in lots less RAM now.) This was intended to be an EZ-GCC
for v2 (although I never tried v1, my first GCC was 2.7.2.1 and DJGPP
2.01? on my 486 in 1997, brrrr, compiling Allegro back then was kinda
slow, and actually 2.95.3 ain't any faster, but it's faster than 3.x
or 4.x, that's for sure.)
> But, I'm having problems. Neither DJGPP 3.4.1 nor 3.3.6 would cross-compile
> stock GCC 3.3.6 failing in the middle of compiling gcc.c complaining about
> an assignments to a read-only variable. Perhaps, I should try DJGPP GCC 3.3.6
> compiling DJGPP GCC 3.3.6 as a cross-compile, but I thought the code for GCC
> hadn't been changed for DJGPP...
I did use the stock DJGPP srcs for GCC 2.95.3, but I dunno if it
matters. Look for a \BUILD.DJG subdir with DJCONFIG.SH. I think I
modified it (barely) and then ran that. That may be your problem if
you're trying to run "configure" manually. You may also not have all
the tools it needs (cp, mv, sed). Also, GCC is pretty annoying in that
you do need specific versions to compile itself. As mentioned, try GCC
3.4.4 if later doesn't work. (I still say I could e-mail it to you.
But that path setup issue is so annoying! Anyways ....)
Comparing files djconfig.sh~ and DJCONFIG.SH
***** djconfig.sh~
export CONFIG_SHELL=bash
dft_target=i586-pc-msdosdjgpp
#
***** DJCONFIG.SH
export CONFIG_SHELL=bash
dft_target=i386-pc-moss
#
*****
***** djconfig.sh~
#
$srcdir/configure --srcdir=$srcdir --disable-shared --verbose \
--with-gxx-include-dir=\\\${prefix}/lang/cxx \
--with-gnu-ld --target=${target-${dft_target}} \
--host=${target-${dft_target}} \
--prefix=\\\$\$DJDIR
***** DJCONFIG.SH
#
$srcdir/configure --srcdir=$srcdir --verbose \
--with-gnu-ld --target=${target-${dft_target}} \
--host=i586-pc-msdosdjgpp \
--prefix=\\\$\$DJDIR
*****
I doubt the whole i386/i586 part makes a difference, but I did it
anyways. And I only wanted C, no C++, so I wiped that line and used
"sh djmake.sh LANGUAGES=c". BTW, I really suck at recompiling GCC, so
I don't honestly know what I'm doing. Or maybe it's that newer GCC has
trouble with older srcs, I dunno. In any event, I never got LIBGCC.A
to recompile, so I just used the original (old) one from the Linux
cross compiler (is that bad? is that wrong? seems to work, at least,
and I dunno what else to do).
> Binutils fails near the end of make with
> error 2. I know from past experience, that once everything is working
> correctly, those mysteriously go away. This is one reason why I prefer to
> always have binaries, but be able to get source instead of the GNU it's
> always source, and never binaries model. Even if the code won't compile
> anymore, the executable will work.
Yes, pre-built binaries are good. Of course, -static helps a lot too,
but GNU/Linux has some severe problems with bloat there (i.e. NetBSD
or Minix aren't nearly as big), dunno why (NLS? reentrancy?).
> > Anyways, I could always just e-mail you the binaries I compiled
>
> I'd rather get it to work on my machine. I've experienced similar problems
> trying to cross-build with DJGPP in the past.
There's probably a cross-build mailing list we could ask. I did
briefly e-mail Bryan (Ford) with a pretty wimpy "Hi, how's it going?"
just to see if he was still around (no response yet). That's a long
shot, though, I doubt he's still interested.
> > > If I can compile it, it should be easier to port or at
> > > least get the code to compile on newer versions. I'm not saying I can get
> > > it working or anything, just that I'll look into it.
>
> > I know, no pressure. It was all your idea anyways. Only try to have
> > some fun with it. ;-)
>
> Sorry, for some reason, I was thinking you compiled moss.exe... Actually,
> with the size of moss.exe being so small, I can't imagine all of the code he
> included actually being used. It's just a matter of determining what was
> used, since I'm not sure that it'll ever compile again in it's current form.
Recompiling MOSS.EXE doesn't give you any examples, so in order to
test it, I had to find a way to build. Of course, not sure which is
easier / better: DOS host or old BasicLinux w/ precompiled 2.7.2 /
2.6. Obviously I'm biased towards the former, but at least the latter
installs on top of DOS and is very lean.
> > You can ask
>
> ./configure --target=i386-moss
>
> ./configure --target=i386-moss --host=i386-pc-msdosdjgpp --build=i386-pc-msd
> osdjgpp
>
> What did you use or do? But, I think I might be using the wrong set of
> sources: stock GNU instead of DJGPP.
I dunno, does stock have BUILD.DJG\djconfig.sh? (GCC's SVN doesn't
have it or else I can't find it.) I would just use stock DJGPP srcs if
I were you.
> > > The MOSS version runs under MS-DOS v7.10, but has "'\n' -> '\r\n'
> issues."
>
> > I have no idea what that means.
>
> Ah, I quoted what you quoted. DOS uses both an ASCII carriage return (CR or
> \r) and linefeed (LF or \n) to move to the beginning of the next line. LF
> in DOS moves down a line. CR moves to the begining of the line. *NIX
> usually uses just LF to do both. Mac's use just CR to do both. This was a
> historical misunderstanding with early ASCII. DJGPP fixes this behind the
> scenes. So, when text just using LF is displayed, it moves down a line, but
> not to the start of the line. The text shows up as a staggered and
> wrap-around look. Think stack of domino's versus stack of domino's with a
> tilt.
I understand all that, just don't know what you're experiencing. Is
the text showing up on the screen incorrectly or being unpacked by
7ZDEC incorrectly or something else? It works in DOSBox, still haven't
tested on real hardware yet. (QEMU + FreeDOS seems to imply that
HIMEMX or JEMM386 won't work but others seem fine, go figure.)
> > Atari Lynx
>
> What? I thought you were younger than that... ;)
I'm 29. I never had a Lynx "back in the day" for whatever reason, but
it had some cool arcade ports. I even bought a used Lynx 2 on eBay a
few years ago (2004?) with games, but it eventually crapped out in
2006 or so (screen stopped working). That's what I get for buying
electronics made in 1991 !!
> >http://www.brynosaurus.com/
>
> I didn't realize he worked on vx32 also... I've read the papers and looked
> it over a few times. It, like many other open projects, has some features I
> like, but it isn't as developed as much as I'd like or going in the
> direction I'd like. In the case of vx32, they just do binary translation to
> implement their sandbox. But, with more development, vx32 could be used as
> an x86 emulator, possibly with much better performance than others.
It claims security, fast speed (even SSE supported), and portability.
He says, "porting to Windows XP should be possible", which would of
course be very very interesting. (Of course, they also intended to
port Inner Worlds to Windows 2000/NT/ME "eventually", and that never
happened.) At least the idea that FreeBSD, Linux, Linux 64-bit, Mac OS
X all work sounds pretty cool.
> > P.P.S. Sebastien, you cross-posted to the wrong group! :-P
>
> I threw on comp.os.msdos.programmer. He posted to the wrong thread there.
> His response was to Herbert Kleebauer in "Adding equal sign as a parameter."
Yeah, I didn't know you were cross posting until I saw that. Fitting
to cross post for a cross compiler. ;-)
BTW, the ELF output from MOSS doesn't run under BasicLinux, which I
vaguely hoped it would. Oh well, can't have it all.
Rod Pemberton
>
> I don't know what changes between releases of Binutils.
From what I could tell, not much.
> I would just use stock DJGPP srcs if
> I were you.
Next attempt...
FYI, the code for MOSS falls under a bazillion licenses. If one removes the
FreeBSD directories - assuming they aren't needed - there are like four or
five or seven licenses. The reason I mention that is that it chops up the
application into many small little files. I reduced it down to just those
which license the primary parts of the DOS extender, those licensed by
Ford's software company. I was hoping that since MOSS was small, that those
files were all that were really needed. Then, I started backfilling in the
missing pieces. 51 files and counting.... No luck on the low file count.
My OS has nearly everything he uses, but it's all in a single file. One.
Since the code pieces are under different licenses, the puzzle pieces can't
be merged together in a coherent manner. I haven't decided whether I'm
going to continue the way I'm going, scrap it, or attempt to figure out how
to compile it "properly"... so I can ignore the stuff that's not needed.
:-) I haven't figured out the correct order that a few files with the same
names are referenced due to the "#include_next" preprocessor directive. I
figured out a few from the code. Otherwise, it looks like it has everything
needed for a complete DPMI host and/or DOS extender.
> Recompiling MOSS.EXE doesn't give you any examples, so in order to
> test it, I had to find a way to build.
If you manage to recompile moss.exe, let me know. I tried out the IW
application. Under Win98SE, it "threw a wrench" at my monitor... It
switched to some mode that wouldn't display. After a reboot, I manually set
my monitor to the lowest setting - which allowed it to switch properly, it
would run, halt, run, halt. It ran on DOS nicely. I'm not sure how well it
would've run on my old 500Mhz machine though.
> I understand all that, just don't know what you're experiencing.
The text is fine. The text alignment is incorrect - due to the missing
carriage return. Are you familiar with unix2dos or dos2unix utilities?
What unix2dos does for text files must be done for text output by the C
compiler so the text is correct for DOS. I can't fully demonstrate because
of the NG line wrap. But, if the decompressor's normal text screen looks
like this, with a's being the screen width:
aaaaaaaaaaaa
Normal
Text
Is
Aligned
Left
This is what it is looks like with the improper EOL:
aaaaaaaaaaaaaa
Normal
Text
Is
A
ligned
Left
It moves down a line, continues, wraps at 80.
> It works in DOSBox,
If it's correctly emulating DOS, then the text should be shifted like the
lower picture... ;-)
> > >http://www.brynosaurus.com/
> >
> > I didn't realize he worked on vx32 also... I've read the papers and
looked
> > it over a few times. It, like many other open projects, has some
features I
> > like, but it isn't as developed as much as I'd like or going in the
> > direction I'd like. In the case of vx32, they just do binary translation
to
> > implement their sandbox. But, with more development, vx32 could be used
as
> > an x86 emulator, possibly with much better performance than others.
>
> It claims security, fast speed
"fast speed" It's the first paper(s) I've read where I actually believed
the speed of emulation claims might be correct... I'm still debating. Most
are total BS.
> Yeah, I didn't know you were cross posting until I saw that. Fitting
> to cross post for a cross compiler. ;-)
I thought one of the programmers there might've been interested in a DOS
project. ;-) Actually, considering they fully implemented a game like that
in '96, I'd think a few people would be jumping at this. '87 Arcade quality
2D when PC's were just getting decent video cards, and low quality 3D DOOM.
It's too bad the source for the game isn't available.
RP
Rod Pemberton
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:gk6cuo$qor$1...@news.tornevall.net...
> "Rugxulo" <rug...@gmail.com> wrote in message
> news:d0ac44e3-772a-44f7...@h20g2000yqn.googlegroups.com...
> >
> > I don't know what changes between releases of Binutils.
>
> From what I could tell, not much.
>
> > I would just use stock DJGPP srcs if
> > I were you.
>
> Next attempt...
>
Building DJGPP GCC 3.3.6 and DJGPP Binutils 2.19 sources with DJGPP GCC
3.3.6 and DJGPP Binutils 2.19 binaries, binutils fails with "Error 2" and
gcc fails to find signal.h and ucontext.h... If your method of using
modifying some script doesn't work, I'm deleting and reinstalling from
scratch. I see no reason why these shouldn't build with configure and make.
Everything is setup just like my two other DJGPP directories...
RP
Rod Pemberton
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
Okay, with your comments, Daniel Borca's guide, I think I got binutils to
compile for DJGPP host and moss target, but GCC is complaining of missing
directories for moss to moss target... I've tried a few rebuilds now. I'm
not sure why the host is incorrect.
RP
Rod Pemberton
Well, a number of changes later, I think I got a moss version of GCC to
compile. It errors where the moss document says it should. Ok, it appears
I'm headed in the wrong direction anyways. One can't compile the FreeBSD
libc on DOS without compiling MOSS on DOS... And, I'm not sure how to get
moss to compile for DOS. So, I'll have to setup a Linux or FreeBSD, and use
the precompiled libs, like I'm assuming you did to compile the 7Z app.
RP
Rugxulo
On Jan 8, 8:36 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:d0ac44e3-772a-44f7...@h20g2000yqn.googlegroups.com...
>
> > I don't know what changes between releases of Binutils.
>
> From what I could tell, not much.
Not for us DJGPPers, anyways. But ELF support might've changed a fair
bit since 1996 (GCC G++ 2.7.2 / Binutils 2.6). Heck, the game was
supposedly written mostly in C++, which surely means it would have
some issues with newer G++ versions (e.g. before both ANSI C++ in 1998
or G++ ABI changes around 3.1 etc).
> > I would just use stock DJGPP srcs if I were you.
>
> Next attempt...
>
> FYI, the code for MOSS falls under a bazillion licenses. If one removes the
> FreeBSD directories - assuming they aren't needed - there are like four or
> five or seven licenses.
He did say in the text that some files weren't needed, that this was
just his working directory. So you may not actually need all that.
> The reason I mention that is that it chops up the
> application into many small little files. I reduced it down to just those
> which license the primary parts of the DOS extender, those licensed by
> Ford's software company.
I think he wrote most of this himself "at home" for the game on a
"shoestring budget". The game itself took 24 people (more or less)
over a span of three years.
> I was hoping that since MOSS was small, that those
> files were all that were really needed. Then, I started backfilling in the
> missing pieces. 51 files and counting.... No luck on the low file count.
> My OS has nearly everything he uses, but it's all in a single file. One.
Don't forget that the game itself was targeted at 486s. You obviously
forget how slow a 486 is. So I assume he wanted to be able to compile
quickly (i.e. in little pieces on a multitasking OS) without issue.
It's a lot slower compiling one big file than only compiling the tiny
modified files.
> Since the code pieces are under different licenses, the puzzle pieces can't
> be merged together in a coherent manner. I haven't decided whether I'm
> going to continue the way I'm going, scrap it, or attempt to figure out how
> to compile it "properly"... so I can ignore the stuff that's not needed.
Sounds complicated. I didn't really check into the extender itself,
just the compiler part (which is pretty much stock GCC + Binutils). An
extender which you can't use isn't very useful. But he did provide a
pre-built MOSS.EXE (thankfully!).
At least, I can't imagine he'd release it if the licenses conflicted,
esp. if he was going to declare it GPL and use GPL compiler tools. I
can only guess he did it that way (e.g. used pieces of FreeBSD) in
order to allow commercial use without problems. (Inner Worlds was
shareware / commercial for a while there.)
> > Recompiling MOSS.EXE doesn't give you any examples, so in order to
> > test it, I had to find a way to build.
>
> If you manage to recompile moss.exe, let me know.
Did you try the pre-built Linux GCC 2.7.2 cross-compiler under
BasicLinux?
> I tried out the IW
> application. Under Win98SE, it "threw a wrench" at my monitor... It
> switched to some mode that wouldn't display. After a reboot, I manually set
> my monitor to the lowest setting - which allowed it to switch properly, it
> would run, halt, run, halt. It ran on DOS nicely. I'm not sure how well it
> would've run on my old 500Mhz machine though.
Before or after installing? The 10 MB .EXE should've unpacked and
created a shortcut or .PIF. And it does sometimes have issues under
other DPMIs (or maybe some select EMS setups), so it's best under real
DOS. At least, it was written for real DOS. Sounds like you didn't
have enough conventional memory free. (See README for some warnings
including that.)
Hard to imagine VGA being incompatible, maybe a driver issue on your
end. Then again, more likely due to not being tested as well on Win9x
(or maybe Windows' driver faults, etc.)
> > I understand all that, just don't know what you're experiencing.
>
> The text is fine. The text alignment is incorrect - due to the missing
> carriage return. Are you familiar with unix2dos or dos2unix utilities?
> What unix2dos does for text files must be done for text output by the C
> compiler so the text is correct for DOS.
I tried real MS-DOS, DR-DOS, and FreeDOS. You're right, it does have
that issue with text not wrapping correctly. That's just a minor nit,
IMHO. You can always pipe it to something else (esp. w/ *nix LF
support) without issue. Obviously he was less interested in text mode
than making his game (gfx, sound, joystick / gravis, etc).
> > It works in DOSBox,
>
> If it's correctly emulating DOS, then the text should be shifted like the
> lower picture... ;-)
You're right, of course, but DOSBox isn't really meant to be 100%
accurate, just "good enough".
> > Yeah, I didn't know you were cross posting until I saw that. Fitting
> > to cross post for a cross compiler. ;-)
>
> I thought one of the programmers there might've been interested in a DOS
> project. ;-) Actually, considering they fully implemented a game like that
> in '96, I'd think a few people would be jumping at this. '87 Arcade quality
> 2D when PC's were just getting decent video cards, and low quality 3D DOOM.
> It's too bad the source for the game isn't available.
I'd bet he'd willing to open source (if found), but then again, I'm
not holding my breath.
P.S. Found another thing DOSEMU supposedly needs: Glibc 2.2 (and
just so you know, Eric Auer couldn't get IW to run under that yet)
Rugxulo
On Jan 9, 11:21 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
>
> > Okay, with your comments, Daniel Borca's guide, I think I got binutils to
> > compile for DJGPP host and moss target, but GCC is complaining of missing
> > directories for moss to moss target... I've tried a few rebuilds now.
> > I'm not sure why the host is incorrect.
>
Did you make sure the host is "i386-pc-msdosdjgpp"?
> Well, a number of changes later, I think I got a moss version of GCC to
> compile. It errors where the moss document says it should. Ok, it appears
> I'm headed in the wrong direction anyways. One can't compile the FreeBSD
> libc on DOS without compiling MOSS on DOS...
Can't compile FreeBSD libc without the MOSS compiler or without
building the extender? (I haven't looked into that, maybe I should.)
> And, I'm not sure how to get
> moss to compile for DOS. So, I'll have to setup a Linux or FreeBSD, and use
> the precompiled libs, like I'm assuming you did to compile the 7Z app.
I did indeed use the already existing libs (e.g. libc.a, libgcc.a) to
build 7zdec, but I used my own rebuild of GCC + BinUtils (DJGPP
"host"), not the 2.7.2 dynamic build of GCC for Linux (although that
seems to work under BasicLinux, if you want to try that).
Did you notice that the "cross"-linker (ld) says it supports these
formats?
GNU ld 2.10.1
Copyright 2000 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
Supported emulations:
i386moss
i386msdos
I think even DJ and Bryan intersected briefly (June 2, 1995) in one
posting way back in the day (according to Google). Lemme find it
(since it made me think, truly or falsely, that you can build
everything with the MOSS-enabled GCC):
http://sourceware.org/ml/gas2/1995/msg00093.html
--------------------------------------------------------------------------------------------------------
Bryan: Here are some very simple patches to GNU ld-950602.
They add a new target `i386-msdos', to go along with the
corresponding target already in bfd and gas.
They also add a new target `i386-moss', which is a DOS
extender
I'll be releasing shortly (I'd like to have support for it
in
the main binutils distribution by the time I release it).
DJ: Please be careful not to confuse the i386-moss work with i386-
go32 or
i386-djgpp work, which is also a dos extender that runs under
ms-dos
and uses binutils, but uses the COFF support instead of ELF.
Anything
that says "msdos" should be appropriate for ALL ms-dos
systems, not
just the moss system. If it will only help moss, use the word
"moss"
in the name.
Bryan: The i386-msdos target is not for any DOS extender at all; it's
for
creating plain 16-bit ("unextended") MS-DOS executables.
--------------------------------------------------------------------------------------------------------
P.S. He announced the extender + cross-compiler on news://comp.os.msdos.programmer
on Feb. 2, 1996 and news://comp.os.linux.announce the next day.
Rod Pemberton
>
> I didn't really check into the extender itself,
> just the compiler part (which is pretty much stock GCC + Binutils).
Yeah, that's what I thought in regards to the C library too. I.e., I was
thinking he was using pretty much stock GLIBC/LIBC, but he's using all those
FreeBSD files for the C library... So, porting or conversion to GLIBC/LIBC
needs to be done too. I think the 'moss' directory is the front end of
moss.exe. The 'mach4-i386' are the low-level parts of moss.exe. I'm not
sure if the 'mach4' directory is being used much. The 'freebsd' directory
is the custom C library.
On the other hand, since the patches to support "i386-moss" don't do much
and moss.exe starts up an ELF a.out, it might be possible to use another
target, i.e., "i386-generic-ELF," which is supported by more recent GCC and
Binutils. The good news in regard to the library is that he was only using
the handful of calls I mentioned previously (if I didn't make a mistake).
> An
> extender which you can't use isn't very useful. But he did provide a
> pre-built MOSS.EXE (thankfully!).
Well, the interesting things to me are:
- moss.exe is different from the moss stub .exe used by the game, setup,
readme
- the moss stub in the game as a standalone .exe will start the a.out or ELF
part of setup.exe and probably readme.exe, but it won't start up the game
which seems to have a bunch more files and a directory...
- 'file' command recognizes the a.out portions of setup.exe and iw.exe as
ELF
- Chris Giese's mbload recognizes the a.out portions as ELF but won't start
them because they load below 1Mb
- both moss.exe and the moss stub will start in DOS under a DPMI host, like
CWSDPMI, but fail to run the a.out part of setup.exe or the game. They fail
with either a paging allocation issue or or a failed memory locking call.
I'm assuming that it uses DPMI under Windows too which might explain the
issues I saw. So, I suspect "raw" mode is what works well.
- the point above means that of the supported startup modes (DPMI, EMS,
VCPI, or raw) that raw is working, but DPMI isn't quite.
- Daniel Borca doesn't seem to have an ELF DPMI startup... (?) I' haven't
looked into how his library or executable startup was setup without it.
The good news is I understand the DPMI mode code for moss.exe. The bad news
is that we probably want raw mode code since it seems to be what is working
the best. I was looking into porting just the DPMI portion to DJGPP and/or
OpenWatcom. But, if the DPMI startup isn't functional, as I found, that
makes it less likely to work...
> At least, I can't imagine he'd release it if the licenses conflicted,
> esp. if he was going to declare it GPL and use GPL compiler tools.
Well, the parts of moss.exe for the DPMI are either GPL or (I think) the
functionality is already in DJGPP. So, the non-GPL parts could possibly be
removed or rewritten.
> > > Recompiling MOSS.EXE doesn't give you any examples, so in order to
> > > test it, I had to find a way to build.
> >
> > If you manage to recompile moss.exe, let me know.
>
> Did you try the pre-built Linux GCC 2.7.2 cross-compiler under
No, I haven't setup any Linux machines. I'd use QEMU, but I don't know how
to transfer files between the QEMU image and my OS. Since this machine
boots USB, I was thinking about buying a larger USB flash drive to setup
Linux with multiple versions of GCC/binutils/LIBC/GLIBC to give me an idea
of how it builds, to allow me to progressly recompile to a newer compiler
and library, etc.
> I tried real MS-DOS, DR-DOS, and FreeDOS. You're right, it does have
> that issue with text not wrapping correctly. That's just a minor nit,
> IMHO. You can always pipe it to something else (esp. w/ *nix LF
> support) without issue. Obviously he was less interested in text mode
> than making his game (gfx, sound, joystick / gravis, etc).
If there is ever a completed port, it'll be fixed then. I've considered a
DOS TSR to convert them just so I can use DOS' "type" on *nix files... It's
just a minor nuisance with *nix files. Personally, I don't like the fact
that DJGPP uses CRLF. I'd prefer to have the compiler just us LF like *nix
and use conversion programs or a TSR to correct. Using two characters
instead of one in C to represent an EOL, complicates much of C's text
abilities and ASCII text processing. Because of this, I always use binary
mode with adjustments to avoid text mode.
> I'd bet he'd willing to open source (if found), but then again, I'm
> not holding my breath.
It'd be nice, but the game isn't important. The additions/changes to the
library and moss.exe might be useful.
> P.S. Found another thing DOSEMU supposedly needs: Glibc 2.2 (and
> just so you know, Eric Auer couldn't get IW to run under that yet)
Download the U7Win9x extender and read what they had to do to get Ultima 7
to work on Windows... It used "Voodoo mode", aka unreal or bigreal mode.
Rod Pemberton
Rugxulo
On Jan 10, 10:16 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm>
wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
> news:eec87f79-da47-45ca...@e3g2000vbe.googlegroups.com...
>
> > I didn't really check into the extender itself,
> > just the compiler part (which is pretty much stock GCC + Binutils).
>
> Yeah, that's what I thought in regards to the C library too. I.e., I was
> thinking he was using pretty much stock GLIBC/LIBC, but he's using all those
> FreeBSD files for the C library...
If he used GLIBC, it would've be v1 anyways (which was forked to
become Linux's libc5), which is too old to be useful these days. At
least current version (2.9) is apparently LGPL.
From what I can tell, there are other C libs for Linux too, e.g.
Newlib, Dietlibc, etc., which may prove more useful, I dunno.
> So, porting or conversion to GLIBC/LIBC
> needs to be done too. I think the 'moss' directory is the front end of
> moss.exe. The 'mach4-i386' are the low-level parts of moss.exe. I'm not
> sure if the 'mach4' directory is being used much. The 'freebsd' directory
> is the custom C library.
As mentioned, I think I saw somewhere that he called it "Mach on DOS",
aka MOSS, so it may indeed use some Mach stuff. But it's really just a
snapshot of his work directory, so some stuff isn't needed.
> On the other hand, since the patches to support "i386-moss" don't do much
> and moss.exe starts up an ELF a.out, it might be possible to use another
> target, i.e., "i386-generic-ELF," which is supported by more recent GCC and
> Binutils. The good news in regard to the library is that he was only using
> the handful of calls I mentioned previously (if I didn't make a mistake).
What's the difference (or advantage) to using generic ELF instead of
what's currently used?
> - both moss.exe and the moss stub will start in DOS under a DPMI host, like
> CWSDPMI, but fail to run the a.out part of setup.exe or the game. They fail
> with either a paging allocation issue or or a failed memory locking call.
It does seem to whine a lot under another DPMI host, but at least my
7zdec example seemed to still run there in some cases. (Didn't it say
"paging = 4096", so he was using 4 MB pages?? Maybe that's the
problem. CWS says 4 MB pages aren't supported under VCPI or DPMI 1.0.)
> I'm assuming that it uses DPMI under Windows too which might explain the
> issues I saw.
It supports the big four like most modern extenders: DPMI, VCPI,
XMS, raw. Obviously Windows won't allow raw or even VCPI (except e.g.
Win 3.1 /S "standard" mode). And Windows does eat up lots of RAM for
itself too.
> So, I suspect "raw" mode is what works well.
It works well in other setups too, e.g. some XMS or some VCPI. At
least, it didn't have any problems under MS-DOS 6.22 HIMEM + EMM386
(or DR-DOS 7.03), only whines a bit under Win 3.1 (but still seemed to
work).
> - the point above means that of the supported startup modes (DPMI, EMS,
> VCPI, or raw) that raw is working, but DPMI isn't quite.
I do think his DPMI support needs improvement, most likely, but I
wouldn't think that "raw" is the only other way of working. Especially
since "raw" isn't really practically used for anything. It just has
some compatibility issues with some (not all) newer software that
didn't exist back then.
> The good news is I understand the DPMI mode code for moss.exe. The bad news
> is that we probably want raw mode code since it seems to be what is working
> the best. I was looking into porting just the DPMI portion to DJGPP and/or
> OpenWatcom. But, if the DPMI startup isn't functional, as I found, that
> makes it less likely to work...
As mentioned, it's not totally broken, just quirky. I'm sure it could
be fixed. I definitely wouldn't prefer to use raw exclusively, and I'm
pretty sure you don't have to.
> > At least, I can't imagine he'd release it if the licenses conflicted,
> > esp. if he was going to declare it GPL and use GPL compiler tools.
>
> Well, the parts of moss.exe for the DPMI are either GPL or (I think) the
> functionality is already in DJGPP. So, the non-GPL parts could possibly be
> removed or rewritten.
I'm not as worried about that as you are (esp. since I'm not a lawyer
and don't understand most licenses anyways).
> > > If you manage to recompile moss.exe, let me know.
>
> > Did you try the pre-built Linux GCC 2.7.2 cross-compiler under
>
> No, I haven't setup any Linux machines. I'd use QEMU, but I don't know how
> to transfer files between the QEMU image and my OS. Since this machine
> boots USB, I was thinking about buying a larger USB flash drive to setup
> Linux with multiple versions of GCC/binutils/LIBC/GLIBC to give me an idea
> of how it builds, to allow me to progressly recompile to a newer compiler
> and library, etc.
You're using Win98 and can boot to DOS mode, so just unzip BasicLinux
on top of your FAT partition. It's only 20 MB unpacked, so it's not
much (only 4 MB or so .ZIP'd). Then just unpack the prebuilt Linux GCC
cross-compiler on top of that: "cd / ; tar xvzf /tmp/moss-0.90-bin-
linux.tar.gz ; export PATH=/usr/local/i386-moss/bin:$PATH"
I don't think QEMU does share files (although there is some
experimental USB crud that I never tried). At least it won't write,
but it can read from host OS:
qemu -m 128 -L . -fda myflop.img -hda myhard.img fat:/armslurp/moss -
boot a
This will boot from floppy, use myhard.img as C:\ (or /dev/hda1 or
whatever) and use \Armslurp\MOSS as D:\ (or /dev/hda2 or whatever).
Then you can copy the files to a writable location (e.g. /tmp) and
edit them there. Of course, if you need to transfer back to your host
OS, you either have to do some FTP trickery or write to myflop.img and
use an extract tool (which is what I typically do). Or even e-mail
yourself if the guest OS supports networking. ;-)
> > I'd bet he'd willing to open source (if found), but then again, I'm
> > not holding my breath.
>
> It'd be nice, but the game isn't important. The additions/changes to the
> library and moss.exe might be useful.
Just seeing some examples as well as supposedly portable code would be
interesting and useful. The game itself is probably pretty huge
although most likely the data itself takes up way more space than the
executable stuff.
> > P.S. Found another thing DOSEMU supposedly needs: Glibc 2.2 (and
> > just so you know, Eric Auer couldn't get IW to run under that yet)
>
> Download the U7Win9x extender and read what they had to do to get Ultima 7
> to work on Windows... It used "Voodoo mode", aka unreal or bigreal mode.
http://members.iinet.net.au/~rsd/five.html
No surprise they had issues. Last I heard, even BOCHS didn't support
unreal (nor DOSBox either). Hence DPMI was added to FASM (although he
claims to use "flat real mode", but I think it's pretty much the same
thing). Sad that the whole point of DPMI was Windows compatibility
(right?), and yet Windows has had so many issues with it over time.
Old Cyrix chips (e.g. early 586s or whatever) couldn't even use unreal
mode, which is yet another blow to such a weirdly useful hack. Still,
is it really that big an advantage over normal coding methods? (Maybe
for speed or easy access to hardware, I dunno.)
Rod Pemberton
> > On the other hand, since the patches to support "i386-moss" don't do
much
> > and moss.exe starts up an ELF a.out, it might be possible to use another
> > target, i.e., "i386-generic-ELF," which is supported by more recent GCC
and
> > Binutils. The good news in regard to the library is that he was only
using
> > the handful of calls I mentioned previously (if I didn't make a
mistake).
>
> What's the difference (or advantage) to using generic ELF instead of
> what's currently used?
Binutils supports i386-moss, but GCC stops i386-moss support at 3.3.6. His
changes look trivial. I don't know if they are. But, even if they are,
you can't use a recent GCC without figuring out how to patch it or using a
different target. It'd be nice to support newer versions. It might be
useful to support older versions too... Is it?
Apparently, you'd prefer older GCC's? Or, what are you interested in using
moss for? Older systems? Smaller systems?
> I do think his DPMI support needs improvement
Well, like I said, that's what'd I'd start with if anything... I'm
familiar. The raw should be similar to what I've in my OS too. I don't
know anything about VCPI. I've got a basic idea of how XMS works, but have
never used it.
> I definitely wouldn't prefer to use raw exclusively, and I'm
> pretty sure you don't have to.
IMO, DPMI can handle everything needed, for DOS at least.
> You're using Win98 and can boot to DOS mode, so just unzip BasicLinux
> on top of your FAT partition. It's only 20 MB unpacked, so it's not
> much (only 4 MB or so .ZIP'd).
Loop on DOS? I thought there was only one that did that... ZipSlack?
> Then just unpack the prebuilt Linux GCC
> cross-compiler on top of that: "cd / ; tar xvzf /tmp/moss-0.90-bin-
> linux.tar.gz ; export PATH=/usr/local/i386-moss/bin:$PATH"
Ok.
Oh, you mean it's using FAT directly. UMSDOS? or newer VFAT? I don't like
the idea of Linux writing to my FAT partitions. I've used it with FAT12 and
FAT16 without problems, but I'm leary, especially with an old version of
Linux writing to my FAT32 partition...
BTW, I thought I got GCC to compile for i386-moss, but it wouldn't install.
I later found a complete moss GCC build installed *OUTSIDE* my DJGPP
directories using *LINUX* directories like /USR/LOCAL/BIN etc. - and they
run on DOS - and they seem to be correct. Man, I don't know what I did...
Canadian cross?... One of the failures was a success! I think I may need
to recompile a few more times until I get a feel for what is correct and
what isn't. I remember being surprised when the one compile said it was
i386-moss to i386-moss and couldn't find ucontext.h...
> I don't think QEMU does share files (although there is some
> experimental USB crud that I never tried). At least it won't write,
> but it can read from host OS:
>
> qemu -m 128 -L . -fda myflop.img -hda myhard.img fat:/armslurp/moss -
> boot a
QEMU 0.8.2 works on Win98SE, but QEMU 0.9.1 needs some help. I posted a
patch here. IIRC, it didn't fix cdrom images. But, (since I didn't/don't
have email to send to them) I don't think ever got to the QEMU team:
http://groups.google.com/group/alt.os.development/msg/b4dc0fc1a7d501fc?hl=en
> Sad that the whole point of DPMI was Windows compatibility
Was it? My understanding was all of these methods VCPI, XMS, DPMI, were
ways to get past the 1Mb barrier created by the 20-bit address range of the
8086 cpu - 16-bit real mode. I.e., they chose to use 16 or 32-bit protected
mode on post 8086 cpu's instead of 16-bit real mode - allowing 24-bit
(80286) and 32-bit addresses (80386) - while still being able to use 16-bit
DOS and BIOS with a 20-bit address space. The 20-bit address space was
required for certain applications - which are always mentioned but never
really identified. Supposedly, CP/M required the A20 wrap, i.e., it
requires a 20-bit address space to work properly. I don't know what else
did.
> Windows has had so many issues with it over time.
IMO, none of them are designed to be controlled by an OS. AFAIK, they are
designed to give dedicated applications control of a larger address space
through the larger address space available to protected mode on later cpu's.
If someone was designing them to work with a more developed OS than DOS,
many of the features would've been disabled or removed, IMO. Much of what's
in them has to do with OS setup, protected mode OS maintenance, and memory
allocation.
> Old Cyrix chips (e.g. early 586s or whatever) couldn't even use unreal
> mode, which is yet another blow to such a weirdly useful hack.
Really? I've got 5V Cyrix... DX2-50 (?, I think...) packed away around
here somewhere. I got it cheap, right after Cyrix's reputation was damaged.
I never had any problems with it. I basically gave the cpu away a number of
years later to a co-worker at the time. I installed it for him too. But,
he returned it about a month later saying his kids complained one of their
games was "flaky" with it. He did say it was much faster. I don't recall
what cpu he had. IIRC, the Cyrix was only supposed to be run in recent (at
the time) motherboards that had a more powerful 5V cpu supply line. I told
him about this in advance so he could check. He was an EE (audio) with many
years of audio design experience and said his PS was sufficient, which was
probably true in general. But, he had an older system so the 5V line itself
might not have been powerful enough. At the time, I took him at his word
since he designed power amplifiers and he should've been able to check
easily. One of his "specialties" was using many high power MOSFET's in
parallel per audio channel to boost the current without causing MOSFET
failures. The MOSFET's were cheaper to use than other solutions, but only
if the circuit was designed to operate them reliably without "blowing up".
Today, an audio EE would probably just use an IGBT.
Rod Pemberton
Rugxulo
On Jan 10, 5:54 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:59d15676-685a-4ad8...@f3g2000yqf.googlegroups.com...
>
> > What's the difference (or advantage) to using generic ELF instead of
> > what's currently used?
>
> Binutils supports i386-moss, but GCC stops i386-moss support at 3.3.6. His
> changes look trivial. I don't know if they are. But, even if they are,
> you can't use a recent GCC without figuring out how to patch it or using a
> different target. It'd be nice to support newer versions. It might be
> useful to support older versions too... Is it?
>
> Apparently, you'd prefer older GCC's? Or, what are you interested in using
> moss for? Older systems? Smaller systems?
I think newer GCCs are harder to boostrap than others. Besides, if you
don't need fancy Core2 optimizations or C99 or C++0x, then you don't
need the latest / greatest. (I do use 4.3.2 on my laptop among others,
but on my older cpus I use 2.95.3 and 3.4.4, respectively.) Newer runs
slower on older machines than older versions do.
> > I do think his DPMI support needs improvement
>
> Well, like I said, that's what'd I'd start with if anything... I'm
> familiar. The raw should be similar to what I've in my OS too. I don't
> know anything about VCPI. I've got a basic idea of how XMS works, but have
> never used it.
Here's a place that has specs for VCPI, EMS, XMS, DPMI, etc.
http://www.filewatcher.com/b/ftp/ftp.lanet.lv/pub/mirror/x2ftp/msdos/programming/specs.0.0.html
And here's what Wikipedia says:
http://en.wikipedia.org/wiki/DOS_Protected_Mode_Interface
http://en.wikipedia.org/wiki/Extended_memory
http://en.wikipedia.org/wiki/Expanded_memory
http://en.wikipedia.org/wiki/VCPI
According to them, DPMI was initially developed for Windows 3.0 by
Microsoft.
And here's what VCPI.DOC says:
"If an EMS emulator with the VCPI interface is installed, a
multitasker and/or
an arbitrary number of DOS-Extender programs which use the VCPI
interface can
be run."
Apparently the "co-ordinators" of VCPI were PharLap and Quarterdeck.
I think VCPI was 32-bits only, always ring 0, and ran only under Win
3.1 /s "standard" mode (not 386 enhanced). So to be able to run under
OS/2 or Win 3.x 386 Enhanced (for true multitasking, not just task
swapping), you need DPMI.
As far as EMS and XMS go, EMS is older (e.g. Jim Leonard's 8088 has 2
MB of *real* EMS, not emulated) while XMS requires a 286. I think
emulated EMS is slower (due to pmode) than XMS (real mode) but doesn't
fragment as much (4k pages). However, some EMS managers limit you to
32 MB EMS, which ain't a lot. XMS v2 could at least use 64 MB
(although 286s were indeed limited to 16 MB). With XMS v3, you can
access a lot more memory (unless your EMM386 lies about what version
it supports, e.g. DR-DOS, which can't even multitask without its
special EMM386). Various programs won't even run (well, if at all)
without EMS: Scream Tracker, Dr. Track, BioMenace, etc. Even Turbo C/C
++ by default will use EMS to speed up compilation but not XMS
(without manual switches).
> > I definitely wouldn't prefer to use raw exclusively, and I'm
> > pretty sure you don't have to.
>
> IMO, DPMI can handle everything needed, for DOS at least.
Probably so. Older DJGPPs before v2 supported the other stuff, but by
v2, they decided DPMI was the way to go.
> > You're using Win98 and can boot to DOS mode, so just unzip BasicLinux
> > on top of your FAT partition. It's only 20 MB unpacked, so it's not
> > much (only 4 MB or so .ZIP'd).
>
> Loop on DOS? I thought there was only one that did that... ZipSlack?
ZipSlack uses kernel 2.4.x with UMSDOS. BasicLinux uses 2.2.x. No
maintainer was available, so 2.6.x doesn't support UMSDOS at all.
> > Then just unpack the prebuilt Linux GCC
> > cross-compiler on top of that: "cd / ; tar xvzf /tmp/moss-0.90-bin-
> > linux.tar.gz ; export PATH=/usr/local/i386-moss/bin:$PATH"
>
> Ok.
Of course, it's a really old GCC (2.7.2), but hey, if it works, it
works.
> Oh, you mean it's using FAT directly. UMSDOS? or newer VFAT? I don't like
> the idea of Linux writing to my FAT partitions. I've used it with FAT12 and
> FAT16 without problems, but I'm leary, especially with an old version of
> Linux writing to my FAT32 partition...
Well, BasicLinux claims to have other newer kernels (which I think
means 2.4.x) on their site somewhere. That should be more stable than
2.2.x if you're worried. They just used 2.2.x for low memory use
(using approx. 5 MB in QEMU, from what I could tell).
> BTW, I thought I got GCC to compile for i386-moss, but it wouldn't install.
> I later found a complete moss GCC build installed *OUTSIDE* my DJGPP
> directories using *LINUX* directories like /USR/LOCAL/BIN etc. - and they
> run on DOS - and they seem to be correct. Man, I don't know what I did...
> Canadian cross?... One of the failures was a success! I think I may need
> to recompile a few more times until I get a feel for what is correct and
> what isn't. I remember being surprised when the one compile said it was
> i386-moss to i386-moss and couldn't find ucontext.h...
I think it assumes the standard *nix installation in /usr/local if you
don't supply a prefix. And yet I tried supplying the stock prefix for
DJGPP, and that still didn't work. Obviously C:\USR\LOCAL isn't a
great place to put it, but I'll have to fiddle with it some more
myself eventually.
> QEMU 0.8.2 works on Win98SE, but QEMU 0.9.1 needs some help. I posted a
> patch here. IIRC, it didn't fix cdrom images. But, (since I didn't/don't
> have email to send to them) I don't think ever got to the QEMU team:
> http://groups.google.com/group/alt.os.development/msg/b4dc0fc1a7d501f...
I'm not sure the Win32 port is even considered anything besides
"alpha" or experimental. But it mostly seems to work okay. I would
suggest VirtualBox, but even that won't run on Win2k anymore. I
dunno ....
Anyways, you could always use FIPS or Partition Resizer (or GParted
liveCD) to shrink your FAT32 a bit, install FreeDOS on a FAT16, and
put BasicLinux on that.
Heck, you could more easily just make a big RAM disk in FreeDOS and
boot BasicLinux on top of that. I'm sure it would run fast, too. That
way there's no risk of messing up your FAT32 if you never write to
it.
> > Sad that the whole point of DPMI was Windows compatibility
>
> Was it? My understanding was all of these methods VCPI, XMS, DPMI, were
> ways to get past the 1Mb barrier created by the 20-bit address range of the
> 8086 cpu - 16-bit real mode.
I think EMS was first, then XMS (286+), then VCPI (386+), then DPMI
(286 or 386). It's really all tied together, trying to protect the
computer from crashes, extend beyond 1 MB of memory, and allow
programs to co-exist in a multitasking environment. Most DOS extenders
prefer DPMI, then VCPI, then XMS, then raw.
> The 20-bit address space was required for certain applications -
> which are always mentioned but never really identified. Supposedly,
> CP/M required the A20 wrap, i.e., it requires a 20-bit address space
> to work properly. I don't know what else did.
I don't know. But the 286 did a few things differently and broke some
compatibility. Bill Gates even allegedly called it a "braindead" chip
(no official way to exit pmode without reset). When the 386 with V86
mode came out, everybody was happy. (What I want to know is why AMD64
can kill V86 and not be called braindead, ugh. I guess they expect
emulation to be "good enough".)
> > Windows has had so many issues with it over time.
>
> IMO, none of them are designed to be controlled by an OS. AFAIK, they are
> designed to give dedicated applications control of a larger address space
> through the larger address space available to protected mode on later cpu's.
DPMI completely is under the host OS' control. You can't switch to
ring 0 at all. You're not allowed to touch certain things. You are at
their mercy. That's why a buggy DPMI server (ahem, Vista) is very
annoying.
> If someone was designing them to work with a more developed OS than DOS,
> many of the features would've been disabled or removed, IMO. Much of what's
> in them has to do with OS setup, protected mode OS maintenance, and memory
> allocation.
Windows provides its own DPMI host, so it's already enabled, the user
just has to use the API. You don't have to switch into anything. It's
already in pmode. Same with OS/2.
> > Old Cyrix chips (e.g. early 586s or whatever) couldn't even use unreal
> > mode, which is yet another blow to such a weirdly useful hack.
>
> Really? I've got 5V Cyrix... DX2-50 (?, I think...) packed away around
> here somewhere. I got it cheap, right after Cyrix's reputation was damaged.
> I never had any problems with it. I basically gave the cpu away a number of
> years later to a co-worker at the time. I installed it for him too. But,
> he returned it about a month later saying his kids complained one of their
> games was "flaky" with it.
I don't know if you mean ran slower or had electrical problems (hinted
at by your other comments). I never had one, but from what I've read,
the FPU on the Cyrix 6x86 was much slower than the Intel Pentium,
hence Quake (compiled by DJGPP, no less) was too slow on that machine.
So people who thought they were saving money on the Cyrix (which was
cheaper, at the time) really couldn't play Quake, so they ended up
playing stuff like Duke Nukem 3D instead (which ran perfectly fine).
To be honest, I'm not sure GCC even supports Cyrix chips anymore (if
ever). I looked around, but apparently only PGCC had some experimental
support for it. (Geode doesn't really count as Cyrix, right?) I think
Debian / Ubuntu just compiles for 486 since some Cyrix "686" can't
handle CMOVs. (GCC has always assumed "i686" supports CMOVs, no matter
what. Some people say that's incorrect.)
http://en.wikipedia.org/wiki/Cyrix
http://www.goof.com/pcg/doc/opt-cyrix6x86.txt
Rod Pemberton
> > > Old Cyrix chips (e.g. early 586s or whatever) couldn't even use unreal
> > > mode, which is yet another blow to such a weirdly useful hack.
> >
> > Really? I've got 5V Cyrix... DX2-50 (?, I think...) packed away around
> > here somewhere. I got it cheap, right after Cyrix's reputation was
damaged.
> > I never had any problems with it. I basically gave the cpu away a number
of
> > years later to a co-worker at the time. I installed it for him too. But,
> > he returned it about a month later saying his kids complained one of
their
> > games was "flaky" with it.
>
> I don't know if you mean ran slower or had electrical problems (hinted
> at by your other comments). I never had one, but from what I've read,
> the FPU on the Cyrix 6x86 was much slower than the Intel Pentium,
> hence Quake (compiled by DJGPP, no less) was too slow on that machine.
> So people who thought they were saving money on the Cyrix (which was
> cheaper, at the time) really couldn't play Quake, so they ended up
> playing stuff like Duke Nukem 3D instead (which ran perfectly fine).
I played both. But, I don't recall off-hand if it was on the Cyrix... I
recall the first cpu that my friends at the time thought DOOM ran well on as
being a "AMD DX2-75." Although that's what I recall, I can't find any
reference to this cpu ever existing, only AMD DX2-80 and Intel DX4-75... I
thought the next cpu I owned was a "DX2-133," but they weren't upto 133 yet
and the next cpu I had was in the 133Mhz class, but I don't know why I
would've gone with a DX2-66 when I had a DX2-50. One of the ones after that
was an odd one: DX4-120. I got it cheap too. The guy couldn't sell them
because everyone knew from the 120 that the cpu ran slower than the 133's...
Anyway, it was clock tripled on 40Mhz bus instead of like the DX4-133 which
was clock quadrupled on a 33Mhz bus. (You can find many references to the
DX4-133, just no photo's on any cpu collection site... Some sites indicate
this chip may have actually been an 5x86. I never saw the chip they used,
so I don't know why they were calling them DX4-133's.) Anyway, I almost
didn't get to use my DX4-120 cpu. My friends kept wanting to test it, buy
it from me, sell it back to me, borrow it for extended time periods, etc. I
can only guess at what they were doing: hoping the higher bus speed and
albeit lower cpu speed would produce better memory throughput for DOOM or
perhaps Quake. Yahoo pulls up comments that some people were able to run
this cpu at 160.
DX4-120
http://www.chipdb.org/cat-dx4-120-14.htm
Rod Pemberton
Rod Pemberton
> > >
> > > You're using Win98 and can boot to DOS mode, so just unzip BasicLinux
> > > on top of your FAT partition. It's only 20 MB unpacked, so it's not
> > > much (only 4 MB or so .ZIP'd).
> >
> > Loop on DOS? I thought there was only one that did that... ZipSlack?
>
> ZipSlack uses kernel 2.4.x with UMSDOS. BasicLinux uses 2.2.x. No
> maintainer was available, so 2.6.x doesn't support UMSDOS at all.
Maybe it was LoopLinux (?). IIRC, the problem, for me, was while it had a
loopback FS on DOS, it couldn't mount VFAT, only UMSDOS.
It seems there is a newer one called RIP Linux, but I don't think it's a
loopback system.
http://www.tux.org/pub/people/kent-robotti/looplinux/rip/
Further down the page:
"If you want to install and boot Linux on a Windows XP/Vista system, read
the readme below. " (README link is bad, but .exe is available.)
Interesting, I have RIPLinux CD, but I can't check to see if it's the
same... (need a cable...).
Ok, I dl'd BasicLinux.
RP
Terence
DOS and he ran it normally in the Vista command line, so there's hope.
I'm aware you need to release the ports woth Userport or Porttalk if
you want I/O control over RS232C and Printer parallel ports. But it
appears there's still transparency without any special add-ons.
My library of asembly written object routines (1980-2009) to be called
from HL languages for DOS services and Text User Interacing still work
fine if you use the MS stack convention.
Rod Pemberton
> On Jan 6, 5:11 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > "Rugxulo" <rugx...@gmail.com> wrote in message
> >
> > > 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...
>
> DOSEMU also needs S-Lang2, IIRC. But I have no idea when DOSEMU was or
> ever will be compiled for Windows.
>
S-Lang? Ok, another C like interpreter... It's interesting to note that it
fully supports C's types which some of the other more well known and closer
to true C interpreters don't.
> > > The stub is 16-bit,
> >
> > You could unstub...
>
> Sure, but I see no advantage there.
>
Just to get rid of the 16-bit code... so the application is 32-bit only (or
mostly so). Sorry, I was thinking you said 32-bits could run "at the same
time as 64-bit stuff."
Previously, you said:
> AMD64 long mode doesn't allow 16-bit
> programs to run at the same time as 64-bit stuff. Only the emulation
> mode allows 16- and 32-bit stuff (but no 64-bit then).
Are you sure about this? Once in long mode, the code size 16/32/64 is
selected by bits in the CS selector. If it works like legacy mode, you
should be able transfer to the new selector by jmp or gate etc. to switch
instruction size while remaining in long mode.
> > > and the C lib does call BIOS and MS-DOS interrupts
> >
> > ... but you can't fix that easily.
>
> It can't be that hard. I mean, people write JIT compilers and VMs all
> the time (e.g. Ruby or Perl).
Well, I had a specific method/situation in mind when I stated that: the
aforementioned Vista 64... For DOS, you'd just need a 64-bit DPMI host.
Using a 64-bit port/compile of DOSBox, if available, might be easiest for
Vista. But, what I was thinking about is when running on an OS, you'd need
to trap all the DPMI calls that DJGPP uses. That likely requires installing
interrupt routines or binary patching of the code. After trapping the DPMI
calls, you'd also need to decode them to get the DOS and BIOS calls. Then,
you need to translate all the DOS and BIOS calls to the OS's API.... All of
that is done in DOSBox already for whatever systems it supports.
> > 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.
>
> Cygwin and MinGW aren't exactly perfect either, still stuck to old
> versions due to .DLL and exception issues (as well as the always-
> problematic lack of maintainers).
>
Well, I've not done much for Windows. I had problems with Cygwin and MinGW.
I don't recall trying LCC-Win32. I've not used OpenWatcom for Windows.
But, I did have good luck with "the other LCC" compiler, Pelles C, but it
was a console application.
http://www.smorgasbordet.com/pellesc/
> Anyways, there have been a (very) few attempts at a 64-bit DOS
> extender, but they're mostly proof of concept and don't do anything
> (or even return cleanly). Hence 64-bit is less interesting to DOS
> users (esp. no V86 mode). But there are DOS ports of certain tools
> that support it. (Good luck building a DJGPP cross-compiler for it!
> GCC is kinda complex / annoying to rebuild.) At the very least are
Well, hopefully for DOS, it should just be a matter of rewritting the 32-bit
DPMI code for 64-bit.
> Agner Fog's ObjConv
Aware of it, haven't used it. Those who have seem to swear by it.
> Nick Kurshev's BIEW
Except for assemblers and compilers, I usually use more primitive tools...
DOS EDIT for most editing. A DOS clone of VI to add/remove from
beginning/end of multiple lines, or, GAWK scripts for files that are too
large for VI. An ancient and no longer available text editor for hex
editing that I'll leave unnamed... ;) My own text and binary programs in C
for anything else: splitting/joining, hex dump/undump, text filters, etc.
--
One tool I have become fond of for my personal OS work is John Fine's
Partcopy. It eliminates rawread/rawrite, etc. It uses a different syntax,
but is equivalent in functionality to *nix's dd command which, AFAIK, has
never been fully ported or implemented on DOS. NASM is another...
> > ELF support in binutils and an ELF target, perhaps "i386-elf" or
> > "i386-generic-ELF", would help OS developers who are using DJGPP.
>
> But there was a COFF bootloader at one time, right? (I know you know
> more than me on this since I don't write OSes, heh.)
Actually, you had me stumped... After a quick check, I found quite a few
COFF related programs by Chris Giese and Alexei Frounze, including
bootloaders... I'm not sure to which you're referring though.
(I wrote this prior to your 3/3 post....)
> But yeah, ELF is
> pretty ubiquitous, so having some support in DJGPP can't hurt.
But, ELF is supported natively by GCC and Multi-boot bootloaders, of which
there are a few CG's MBLOAD, GRUB, DOS4GRUB, etc.
> > 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.
>
> It would only optionally replace it. Remember that the DJGPP/ELF third-
> party experimental hack kept both COFF and ELF support. (And boy, -
> static ELF is much bigger than COFF, sheesh. WTF?!)
I haven't used Daniel Borca's version yet. I'll probably try it eventually
just to check out ELF support. Of course, we should expect dynamic ELF from
DJGPP... ;-)
> > 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
>
> MOSS might be too minimal for GLIBC
True. Well, I think DJGPP uses about 170 DOS, BIOS, DPMI calls. I've
attempted to determine the number of "primitives", the underlying function
calls, that are required to build GLIBC, but I had problems. Linux 2.6.17
Kernel uses 290 syscalls, so GLIBC must use fewer. I didn't count other
recent versions, but there was a large increase in the number Linux versions
used just prior to that, so at most I'd figure half that. I'd figure most
the important ones came first and very early. Linux 0.01 has about 40
completed syscalls. Even at half the 290 figure, I'd think the estimate is
really high since Redhat's newlib and PJ Plauger's standard C library only
require 18-20 functions to implement, but they are ANSI/ISO C and have no
POSIX... My guess is 50-110 and hoping for the low side.
> I've heard it said that DOS is only viable for
> games, but nobody seems to be writing many of those anymore.
Well, I think there are a few groups of DOS users who don't comingle much:
programmers (DJGPP, OpenWatcom), game programmers (Allegro), gamers
(DOSBox), users (FreeDOS, DR-DOS, MS-DOS)
> > It seems that MOSS is using the following "primitives" or syscalls:
>
> It would be interesting to see an actual app running via MOSS
Yup... (Written before you did!)
Hopefully, I finished this post... I'm posting it anyway.
Rod Pemberton
Jim Michaels
> I have used DJGPP for years. The problem is this my executable does
> not
> that
> will run on his machine with DGJPP. my machine is XP I want it to run
> on other machines.
>
> Some have said to use MinGW but I don't want to replace my DJGPP
> I would only use MinGW infrequently if I have to go down that path.
> I am not as good as I should be on how to set up a batch file or two
> that I could execute in the command mode. So that I could tempoarly
> change to use MinGW and then another batch file to get back to my
> standard DJGPP mode.
>
> Thanks
> Dave
My best understanding is that Windows 64-bit OS's do not come with
command.com. instead they come with cmd.exe, a 32-bit or 64-bit
native shell. If you want to run MS-DOS applicaitons, you are out of
luck on 64-bit versions of the OS. try buying a 32-bit OS if you
intend to do development or run MS-DOS applications. I am not sure,
but I think Vista 32-bit *may* come with command.com - ask a friend
who has it or ask someone on the 'net.
Another possiblity to run DOS applications that was suggested is
VMWARE or other VM (Virtual Machine) software that can run FreeDOS.
Jim Michaels
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
Robert Riebisch
> I would really like to see a gcc compiler for the windows platform.
That's already available for years and is called "MinGW".
> 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.
??
--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!
Rugxulo
On Jan 12, 2:10 am, Jim Michaels <jmich...@yahoo.com> wrote:
>
> My best understanding is that Windows 64-bit OS's do not come with
> command.com. instead they come with cmd.exe, a 32-bit or 64-bit
> native shell.
The COMMAND.COM that modern Windows use (e.g. XP) is from Windows ME.
> If you want to run MS-DOS applicaitons, you are out of
> luck on 64-bit versions of the OS.
AMD64 doesn't support 16-bit, so unless MS wants a cpu emulator a la
DOSBox or just to somehow emulate the 16-bit stuff, it won't work. I
wish they would, but NTVDM is deprecated, so they don't really care
anymore.
> try buying a 32-bit OS if you
> intend to do development or run MS-DOS applications. I am not sure,
> but I think Vista 32-bit *may* come with command.com - ask a friend
> who has it or ask someone on the 'net.
Yes, Vista 32-bit (which I'm running now, which is forced on everybody
these days) runs some DOS stuff, just not as much as XP and not as
stable. And since it's the same kernel as 2k3 or Win7, that doesn't
bode well for the future.
> Another possiblity to run DOS applications that was suggested is
> VMWARE or other VM (Virtual Machine) software that can run FreeDOS.
The problem is that V86 mode (which AMD64 lacks) is fast unlike full
emulation (DOSBox or BOCHS), which can be pretty slow. I've found QEMU
slower than VirtualBox, but at least the former allows "fat:/mydir/
mysub" access to host files (but not write). In short, even if it's
fast enough, compatible enough, or "free" enough, it might have file
sharing issues. And you need more and more RAM, which is why some
people are moving to x86-64 in the first place. (FreeBSD among others
supports PAE, not sure why that isn't more popular. Maybe driver
incompatibility, I dunno.)
Rugxulo
On Jan 11, 10:26 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm>
wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:4563e62e-7382-4c6a...@i18g2000prf.googlegroups.com...
>
> > On Jan 6, 5:11 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > > "Rugxulo" <rugx...@gmail.com> wrote in message
>
> > > > The stub is 16-bit,
>
> > > You could unstub...
>
> > Sure, but I see no advantage there.
>
> Just to get rid of the 16-bit code... so the application is 32-bit only (or
> mostly so). Sorry, I was thinking you said 32-bits could run "at the same
> time as 64-bit stuff."
Yes, it can, but you still need to somehow emulate the BIOS and DOS
calls.
> Previously, you said:
>
> > AMD64 long mode doesn't allow 16-bit
> > programs to run at the same time as 64-bit stuff. Only the emulation
> > mode allows 16- and 32-bit stuff (but no 64-bit then).
>
> Are you sure about this? Once in long mode, the code size 16/32/64 is
> selected by bits in the CS selector. If it works like legacy mode, you
> should be able transfer to the new selector by jmp or gate etc. to switch
> instruction size while remaining in long mode.
I've never used 64-bit except for a few trial boots via Linux, but
this is what I've read. I don't think you can switch back to legacy /
compatibility mode without pretty much disabling all 64-bit processes.
You can run 32-bit side-by-side with it, but not 16-bit.
> > > > and the C lib does call BIOS and MS-DOS interrupts
>
> > > ... but you can't fix that easily.
>
> > It can't be that hard. I mean, people write JIT compilers and VMs all
> > the time (e.g. Ruby or Perl).
>
> But, what I was thinking about is when running on an OS, you'd need
> to trap all the DPMI calls that DJGPP uses. That likely requires installing
> interrupt routines or binary patching of the code. After trapping the DPMI
> calls, you'd also need to decode them to get the DOS and BIOS calls. Then,
> you need to translate all the DOS and BIOS calls to the OS's API.... All of
> that is done in DOSBox already for whatever systems it supports.
Haven't tried CVS yet, but current DOSBox ain't the fastest thing in
the world. It's good for old games but not for compiling with DJGPP.
Of course, that's beyond its design goals anyways, just saying ....
FYI, you can get latest DOSBox 0.72 on two small-ish Linux distros:
antiX Mepis and CDlinux. I don't know of any including DOSEMU. Then
again, not all even include GCC because "not everybody is a
developer". Well, not everybody wants Firefox / OpenOffice / AbiWord /
Gnumeric on *every single distro* either. Bah, I almost wish there was
a DOSnix distro.
> > Cygwin and MinGW aren't exactly perfect either, still stuck to old
> > versions due to .DLL and exception issues (as well as the always-
> > problematic lack of maintainers).
>
> Well, I've not done much for Windows.
Me either.
> I had problems with Cygwin and MinGW.
They both work pretty well except for minor corner cases (experimental
builds are buggy and MSVCRT's tmpfile() used by "current" MinGW hates
Vista). But I haven't exhaustively tested 'em or anything.
> I don't recall trying LCC-Win32. I've not used OpenWatcom for Windows.
> But, I did have good luck with "the other LCC" compiler, Pelles C, but it
> was a console application.
>
> http://www.smorgasbordet.com/pellesc/
Haven't tested all of those, but I do have OpenWatcom installed, it's
quite nice, and the Win32 part works well (although my use of non-DOS
compiling is limited). It's also smaller and static compiles, so
no .DLL issues. But I'm not sure if this supports POSIX at all (doubt
it). But hey, its Win32 compiles also run under HX. :-D
> > Anyways, there have been a (very) few attempts at a 64-bit DOS
> > extender, but they're mostly proof of concept and don't do anything
> > (or even return cleanly). Hence 64-bit is less interesting to DOS
> > users (esp. no V86 mode). But there are DOS ports of certain tools
> > that support it. (Good luck building a DJGPP cross-compiler for it!
> > GCC is kinda complex / annoying to rebuild.) At the very least are
>
> Well, hopefully for DOS, it should just be a matter of rewriting the 32-bit
> DPMI code for 64-bit.
Bigger and more registers is good, but I don't think it helps as
dramatically as marketing execs would like us to believe.
> > Agner Fog's ObjConv
>
> Aware of it, haven't used it. Those who have seem to swear by it.
Try this (2.02, latest is 2.03) DOS port by Japheth if you're curious:
http://www.japheth.de/Download/objconv.ZIP
http://www.japheth.de/Download/objconvs.ZIP
> > Nick Kurshev's BIEW
>
> Except for assemblers and compilers, I usually use more primitive tools...
> DOS EDIT for most editing. A DOS clone of VI to add/remove from
> beginning/end of multiple lines, or, GAWK scripts for files that are too
> large for VI. An ancient and no longer available text editor for hex
> editing that I'll leave unnamed... ;) My own text and binary programs in C
> for anything else: splitting/joining, hex dump/undump, text filters, etc.
DOS EDIT is way too primitive for my needs, I prefer TDE. I also use
VILE sometimes. Both are compiled by DJGPP, so there are no low memory
limits. If you only use VI for simple things, try sed. ;-)
For hex editing, I use both HIEW and BIEW, but the latter is mostly
better in that it's GPL, compiled by DJGPP, supports up through x86-64
(instead of P3 only), and is optionally also a real to-file
disassembler with opcode coloring for easy compatibility checking.
> One tool I have become fond of for my personal OS work is John Fine's
> Partcopy. It eliminates rawread/rawrite, etc. It uses a different syntax,
> but is equivalent in functionality to *nix's dd command which, AFAIK, has
> never been fully ported or implemented on DOS. NASM is another...
FD Diskcopy works fairly well. And I still use Raread on occasion
(since I think Diskcopy does something Vista doesn't like, e.g.
somehow implies "forbidden" full-screen, meh, I'll have to debug that
eventually).
> > > 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.
>
> > It would only optionally replace it. Remember that the DJGPP/ELF third-
> > party experimental hack kept both COFF and ELF support. (And boy, -
> > static ELF is much bigger than COFF, sheesh. WTF?!)
>
> I haven't used Daniel Borca's version yet. I'll probably try it eventually
> just to check out ELF support. Of course, we should expect dynamic ELF from
> DJGPP... ;-)
It actually works, so by default that means it's pretty good! ;-)
http://www.geocities.com/dborca/djgpp/elf/djelf.html
Features include:
* ELF executables which run in True Flat mode
* compatible with Linux shared objects
* dynamically loadable libc.so, libm.so, libstdc++.so
* can still link against static libraries (libc.a, ...)
* requires no change to C/C++ code, only minor changes to Asm code
> > MOSS might be too minimal for GLIBC
>
> True. Well, I think DJGPP uses about 170 DOS, BIOS, DPMI calls. I've
> attempted to determine the number of "primitives", the underlying function
> calls, that are required to build GLIBC, but I had problems. Linux 2.6.17
> Kernel uses 290 syscalls, so GLIBC must use fewer. I didn't count other
> recent versions, but there was a large increase in the number Linux versions
> used just prior to that, so at most I'd figure half that. I'd figure most
> the important ones came first and very early. Linux 0.01 has about 40
> completed syscalls. Even at half the 290 figure, I'd think the estimate is
> really high since Redhat's newlib and PJ Plauger's standard C library only
> require 18-20 functions to implement, but they are ANSI/ISO C and have no
> POSIX... My guess is 50-110 and hoping for the low side.
GLIBC seems to only compile with GCC and only for a billion Linuxes
(and GNU Hurd, surprisingly). That alone might make it somewhat
annoying, compatibility-wise.
> > I've heard it said that DOS is only viable for
> > games, but nobody seems to be writing many of those anymore.
>
> Well, I think there are a few groups of DOS users who don't comingle much:
> programmers (DJGPP, OpenWatcom), game programmers (Allegro), gamers
> (DOSBox), users (FreeDOS, DR-DOS, MS-DOS)
The DOS community is heavily fractured, and it doesn't always get
along.
And BTW, current Allegro WIP versions dropped DOS support, so stick
with 4.2.2 or whatever if you need it. (Yes, people still use it. I
think RAINE had a DOS compile recently.)
EDIT: Seems Allegro 4.2.2 is buggy in his eyes, so he provides his own
patched version:
http://rainemu.swishparty.co.uk/
P.S. Somebody out there feel free to recompile it and refresh the
online copy:
ftp://ftp.delorie.com/pub/djgpp/beta/v2tk/allegro/all422[ab].zip
(old, buggy)
> Hopefully, I finished this post... I'm posting it anyway.
Cool. :-)
Robert Riebisch
> And BTW, current Allegro WIP versions dropped DOS support, so stick
> with 4.2.2 or whatever if you need it. (Yes, people still use it. I
> think RAINE had a DOS compile recently.)
>
> EDIT: Seems Allegro 4.2.2 is buggy in his eyes, so he provides his own
> patched version:
What's buggy?
wmcb...@gmail.com
> 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.
Yeah, that's that gonna happen.
I'm sure the name looks like gibberish to some people, but it has
historical significance and ongoing meaning. The "curses" part, as
you've already hinted, is a reference to cursor control. But more
specifically, it's named after the original Unix "curses" library --
and more than just named for it, it's a clone of it. Almost all the
functions, etc., are derived from that original, and it continues to
aim at compatibility with other implementations, like ncurses. It also
aims at conformance to the X/Open Curses specification:
http://www.opengroup.org/onlinepubs/007908799/xcurses/curses.h.html
You could say the original curses library's name was a bit cutesy,
but, what's done is done -- it's established. And for me, cross-
platform development, and especially the ability to port Unix software
to non-Unix platforms, is the primary purpose of PDCurses.
As for the "PD", it stands for "public domain". In the beginning, it
was "PCcurses" -- curses for the MSDOS PC. (PCcurses, like ncurses,
was derived from Pavel Curtis' original ncurses, also sometimes
referred to as "pcurses".) Then it expanded to other platforms. Being
"PD" may not really be its distinguishing feature, although it was
rare at the time. But it's had this name (and status) for something
like 19 years now.
wmcb...@gmail.com
> Yeah, that's that gonna happen.
should read "Yeah, that's not gonna happen."
Rod Pemberton
> You're using Win98 and can boot to DOS mode, so just unzip BasicLinux
> on top of your FAT partition. It's only 20 MB unpacked, so it's not
> much (only 4 MB or so .ZIP'd). Then just unpack the prebuilt Linux GCC
> cross-compiler on top of that: "cd / ; tar xvzf /tmp/moss-0.90-bin-
> linux.tar.gz ; export PATH=/usr/local/i386-moss/bin:$PATH"
Well, that's a no go... with an error saying it couldn't find FS.IMG.
FS.IMG is there. BASLIN is there. But, I ran it off of a USB flash drive
using legacy BIOS support. That is likely the problem: lack of legacy USB
device support in BasicLinux. Unfortunately, except for the CD-ROM, I don't
have any "legacy" physical (by that I mean has "rotating platters") disk
drives in this machine. The drives I've got all work through modern
interfaces: USB, SATA. The internal HD is a SATA SSD (no moving parts and
_exceptionally_ quiet), my other HD is an external USB (likely a normal
"rotating platters" HD inside...), and the solid-state USB flash drive
effectively "replaces" the floppy... I've been intending to buy a floppy,
but I don't have one yet. One solution might be to pull some older hardware
from another machine, but I'm not motivated to do that.
I also looked at the Debian windows installer. It, like most Linux
installs, want's to partition my disks... a definate no-no. If I had a
physical HD, instead of an SSD, I'd _consider_ defraging it and
repartitioning. I repartitioned an existing, full-of-data, drive once:
scary...
But, with an SSD, defraging is unecessary, prematurely wears out the device,
and takes exceptionally longer than normal drive access (I tried to do so
after a minimal install of my OS...). Since Win98SE boots in 2 seconds flat
using "MS-DOS compatability mode" (SATA as emulated IDE), what's the point?
Oh, I'd *love* to have SATA support in Win98SE... So, I have zero intention
of repartitioning or defraging. What I need is a Linux with a modern
kernel, 2.6 series, with GCC, Binutils, GLIBC, related compiler tools, and
Tso's FDISK. It'd need a statically compiled kernel that is compiled for
loopback on DOS with VFAT, not UMSDOS, and which works with Loadlin. Of
course, it'd also need support for my devices which are SATA and USB based,
not IDE or floppy. Due to the way Linux installs today, I'm thinking this
is an unreal request. In all likelihood, I'd have to install Linux to so I
can create the needed DOS useable Linux by myself.
Rod Pemberton
Rugxulo
On Jan 13, 4:03 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:59d15676-685a-4ad8...@f3g2000yqf.googlegroups.com...
>
> > You're using Win98 and can boot to DOS mode, so just unzip BasicLinux
> > on top of your FAT partition. It's only 20 MB unpacked, so it's not
> > much (only 4 MB or so .ZIP'd). Then just unpack the prebuilt Linux GCC
> > cross-compiler on top of that: "cd / ; tar xvzf /tmp/moss-0.90-bin-
> > linux.tar.gz ; export PATH=/usr/local/i386-moss/bin:$PATH"
>
> Well, that's a no go... with an error saying it couldn't find FS.IMG.
> FS.IMG is there. BASLIN is there. But, I ran it off of a USB flash drive
> using legacy BIOS support. That is likely the problem: lack of legacy USB
> device support in BasicLinux.
Right, I think 2.2.x doesn't support USB. You may have to upgrade the
kernel to 2.4.x. A quick search didn't find one for BL, but it's
probably there somewhere. (BasicLinux claims to be compatible with
Slackware 4.0, too. Maybe they have one.)
> Unfortunately, except for the CD-ROM, I don't
> have any "legacy" physical (by that I mean has "rotating platters") disk
> drives in this machine. The drives I've got all work through modern
> interfaces: USB, SATA. The internal HD is a SATA SSD (no moving parts and
> _exceptionally_ quiet), my other HD is an external USB (likely a normal
> "rotating platters" HD inside...), and the solid-state USB flash drive
> effectively "replaces" the floppy... I've been intending to buy a floppy,
> but I don't have one yet. One solution might be to pull some older hardware
> from another machine, but I'm not motivated to do that.
Well, as mentioned, QEMU + QEMU-IMG + FreeDOS + BasicLinux + FAT12
floppy .IMG to save to (which you can extract files from for DOS)
might work with the pre-compiled i386-moss-gcc. Okay, so that's a
long, roundabout method, but it works. There's also other things (e.g.
Virtual Floppy Drive) for Windows, but not sure if it runs on Win9x.
> I also looked at the Debian windows installer. It, like most Linux
> installs, want's to partition my disks... a definate no-no. If I had a
> physical HD, instead of an SSD, I'd _consider_ defraging it and
> repartitioning. I repartitioned an existing, full-of-data, drive once:
> scary...
Okay, so that might be a bit much, but they say it works. I've never
tried either, so maybe I shouldn't suggest that. ;-) But even
Ubuntu brags about having a Win32 installer now.
> Oh, I'd *love* to have SATA support in Win98SE... So, I have zero intention
> of repartitioning or defraging. What I need is a Linux with a modern
> kernel, 2.6 series, with GCC, Binutils, GLIBC, related compiler tools, and
> Tso's FDISK. It'd need a statically compiled kernel that is compiled for
> loopback on DOS with VFAT, not UMSDOS, and which works with Loadlin. Of
> course, it'd also need support for my devices which are SATA and USB based,
> not IDE or floppy. Due to the way Linux installs today, I'm thinking this
> is an unreal request. In all likelihood, I'd have to install Linux to so I
> can create the needed DOS useable Linux by myself.
I don't know, I'm far from a Linux guru. There are a billion distros,
and most aren't exactly oriented towards DOS-friendliness.
P.S. I did rebuild GCC 2.95.3 (C only) and BinUtils 2.16.1 via DJGPP
for MOSS target, and it seems to work (using /lib/gcc-lib/i386-pc-moss/
2.953/ to hold most everything). I probably organized it wrong, but
for now, who cares. I haven't rebuilt MOSS.EXE yet (and not sure I
can) although I did weakly try (and fail). And as far as binding the
extender to the a.out file, it seems it won't work (MKEXE.SH) because
of lacking "bsdboot.o". You may be able to bind other files to the
a.out itself by using a wrapper linked via ld (see broken script
above), but I haven't tried that. And still no word from Bryan, so I
give up hope on that ....
Anyways, for anybody else's benefit, here's a working binary build of
MOSS / ELF target hosted by DJGPP (GCC + BinUtils + libs + headers +
extender source) w/ 7zdec example as simple testcase. The only thing
this doesn't include is (obviously) the GCC and BinUtils sources,
which I have on my site too. This may expect LFNs due to /i386-pc-
moss/ yet I don't know an obvious way around that yet. But hey, it
works, so use DOSLFN if needed. (I compressed via 7-Zip to save space,
but I did at least add the DOS sfx from Kostylev's 4.58 p7zip compile,
so just rename to .EXE and it should unpack fine, needs 16 MB space,
oh noes!).
http://rugxulo.googlepages.com/moss-dj.7z (3 MB)
http://rugxulo.googlepages.com/gcc2953s.tbz (8 MB, sources only)
http://rugxulo.googlepages.com/bnu2161s.tbz (9 MB, sources only)
P.S. Here's what Bryan's TODO said back then (1996):
* Get rid of some of the stupid hard-coded constants, such as "a.out"
and the remote GDB serial line and enable flag.
* Translation from forward slash to backslash in file operations.
* POSIX-compatible translation for tty-like devices (console, serial
ports, etc.)
* Use EMS pages when available.
* Create a /dev/tty pseudo-file referring to the console.
* Support for loading other executables and other fancy features.
* Native development under DOS.
* Compatibility with DJGPP and/or EMX executables
Rod Pemberton
>
> Well, as mentioned, QEMU + QEMU-IMG + FreeDOS + BasicLinux + FAT12
> floppy .IMG to save to (which you can extract files from for DOS)
> might work with the pre-compiled i386-moss-gcc. Okay, so that's a
> long, roundabout method, but it works.
Well, I was thinking of a few things along those lines. In addition to
"mounting" .iso and FAT images, QEMU should be able to "mount" a DOS
directory with the "fat:<DOS path>" option to hda/hdb, i.e., the
mysteriously not well documented if at all vvfat option (see QCOW on
Wikipedia...). I also thought about using .iso images such as FreeDOS and
Linux. The problem is that under Linux it's easy to add to and extract from
images, just use "mount" with the appropraite options and standard copy
utilities. But, with Windows there is no default way to add to or extract
from images. The ability to *both* add to or extract from is usually only a
feature of compression programs for the specific compression format.
However, the ability to extract from many image types is widely available
with many programs such as WinZip/PkZip, 7-Zip, IsoBuster, DJGPP
cpio/rpm/tar/gzip, etc. So, while it's easy to extract from such images,
it's not so easy to insert files. E.g., how do you add to a FAT12.img or
Linux.iso? If QEMU-IMG allows one to add to images, instead of just
creating blank images, I missed that. It seems QEMU is where the "mounting"
options are and it only supports a handful of filesystem types (no ext2).
Maybe I need to research the Linux "cloop" option to see what it does. Or,
perhaps, the "raw" option is sufficient... So, anyway, I don't currently
know of any utilities or QEMU options that will do so. As I understand it,
the MOSS files have to be decompressed and inserted into a directory in
BasicLinux's FS.IMG, which is probably ext2 gzipped. I can handle the gzip.
I'm not sure what to do with the ext2 under Windows and without Linux
available... So, while the compression method is standard, the filesystem
isn't for Windows. I.e., I could uncompress it, but not add files to it.
Now, if I had a floppy disk drive in this machine, I could use a FAT12 image
with QEMU and then copy to and from a floppy or ramdisk using that image to
add to and extract from it, perhaps using say partcopy.exe to move the image
back and forth. This assumes that BasicLinux supports FAT12 and can mount
it. But, without a floppy, I'm forced to find some other utilities to write
to needed images, or I'm forced to setup the flash drive as a floppy, which
is tedious but doable, I guess. This is really really round-about, and I'm
not sure yet that Windows QEMU supports USB drives with floppy images...
So, I'm going to sleep on it. Maybe I'll locate what I think I need or
would prefer, later.
> Okay, so that might be a bit much, but they say it works. I've never
> tried either, so maybe I shouldn't suggest that. ;-) But even
> Ubuntu brags about having a Win32 installer now.
I saw that too. I didn't try it suspecting the same partition issues. Due
to the size of modern Linux, I suspect that few of them setup as DOS
loopback filesystems. I was thinking about looking at MetroPipe's Portable
Privacy Machine to see what they are using. It supposedly runs from a USB
drive, so it'd be odd for them to use ext2 with Windows instead of using
FAT12/16 since one would want to copy files to/from the image. Given it's
purpose, it's likely though that the compiler toolchain isn't there...
Rod Pemberton
Rugxulo
On Jan 14, 1:21 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:fed9d4c7-d6a7-4780...@r40g2000yqj.googlegroups.com...
>
> > Well, as mentioned, QEMU + QEMU-IMG + FreeDOS + BasicLinux + FAT12
> > floppy .IMG to save to (which you can extract files from for DOS)
> > might work with the pre-compiled i386-moss-gcc. Okay, so that's a
> > long, roundabout method, but it works.
>
> Well, I was thinking of a few things along those lines. In addition to
> "mounting" .iso and FAT images, QEMU should be able to "mount" a DOS
> directory with the "fat:<DOS path>" option to hda/hdb, i.e., the
> mysteriously not well documented if at all vvfat option (see QCOW on
> Wikipedia...). I also thought about using .iso images such as FreeDOS and
> Linux. The problem is that under Linux it's easy to add to and extract from
> images, just use "mount" with the appropraite options and standard copy
> utilities. But, with Windows there is no default way to add to or extract
> from images. The ability to *both* add to or extract from is usually only a
> feature of compression programs for the specific compression format.
> However, the ability to extract from many image types is widely available
> with many programs such as WinZip/PkZip, 7-Zip, IsoBuster, DJGPP
> cpio/rpm/tar/gzip, etc. So, while it's easy to extract from such images,
> it's not so easy to insert files. E.g., how do you add to a FAT12.img or
> Linux.iso?
Adding to a FAT12 image can be done in various ways, e.g. using G.
Vollant's Extract or Alexei Frounze's IMGCPY (found in his FAT lib).
But I typically prefer using a FAT12 .img and mounting it via Linux on
QEMU, then just copying as needed (with fat:/blah if necessary). Maybe
TIMAGE10.ZIP helps too in DOS, I forget.
Dunno about adding to .ISO, even IZarc (Win32) only extracts, not sure
about 7-Zip, almost definitely the same. I guess the only real way is
to create another .ISO from MKISOFS or whatever (which Alexei also has
pre-compiled for DOS in his FAT lib):
http://www.winimage.com/extract.htm
http://alexfru.narod.ru/os/fat/fat.html
http://www.frontiernet.net/~fys/zips/fat-2006-12-03.zip (mirror)
ftp://garbo.uwasa.fi/pc/diskutil/timage10.zip
> If QEMU-IMG allows one to add to images, instead of just
> creating blank images, I missed that. It seems QEMU is where the "mounting"
> options are and it only supports a handful of filesystem types (no ext2).
> Maybe I need to research the Linux "cloop" option to see what it does. Or,
> perhaps, the "raw" option is sufficient... So, anyway, I don't currently
> know of any utilities or QEMU options that will do so. As I understand it,
> the MOSS files have to be decompressed and inserted into a directory in
> BasicLinux's FS.IMG, which is probably ext2 gzipped. I can handle the gzip.
> I'm not sure what to do with the ext2 under Windows and without Linux
> available...
I've never tried QEMU-IMG very much, only a handful of times, and only
then for HD images for guest OSes (e.g. ZipSlack, which lacks libc5,
BTW).
There is supposedly an ext2 driver for Windows, but I'm not sure where
or which versions it supports (as I never used it). :-/
Just try this: create a small (50 MB) HD image via QEMU-IMG,
"format" and "sys c:" it via FreeDOS to make it FAT, use the -hdb fat:/
mydir/blah QEMU option to let you read from your host OS (e.g. put the
BasicLinux .ZIP there as well as the MOSS Linux cross-compiler), then
just use normal DOS tool (e.g. DJTAR) to unpack the BasicLinux .ZIP
from D:\ to that HD image. Then you should be able to boot BasicLinux
on top of FreeDOS and then mount D:\ drive (/dev/hdb1 or whatever) in
Linux and "cd / ; tar xvzf /tmp/moss-0.90-bin-linux.tar.gz ; export
PATH=/usr/local/i386-moss/bin:$PATH" and then type "gcc -v" and see
what happens. (Should work. At least it did for me.)
> So, while the compression method is standard, the filesystem
> isn't for Windows. I.e., I could uncompress it, but not add files to it.
> Now, if I had a floppy disk drive in this machine, I could use a FAT12 image
> with QEMU and then copy to and from a floppy or ramdisk using that image to
> add to and extract from it, perhaps using say partcopy.exe to move the image
> back and forth. This assumes that BasicLinux supports FAT12 and can mount
> it.
It can. FAT12 is pretty ubiquitous.
P.S. Since you're interested in OSes, have you ever tried OctaOS? (Not
trying to wear you out or start yet another tangent, heh, just that it
does some cool stuff):
Rod Pemberton
> Just try this: create a small (50 MB) HD image via QEMU-IMG,
> "format" and "sys c:" it via FreeDOS to make it FAT, use the -hdb fat:/
> mydir/blah QEMU option to let you read from your host OS (e.g. put the
> BasicLinux .ZIP there as well as the MOSS Linux cross-compiler), then
> just use normal DOS tool (e.g. DJTAR) to unpack the BasicLinux .ZIP
> from D:\ to that HD image. Then you should be able to boot BasicLinux
> on top of FreeDOS and then mount D:\ drive (/dev/hdb1 or whatever) in
> Linux and "cd / ; tar xvzf /tmp/moss-0.90-bin-linux.tar.gz ; export
> PATH=/usr/local/i386-moss/bin:$PATH" and then type "gcc -v" and see
> what happens. (Should work. At least it did for me.)
Okay, I must've been thinking way too hard... ;) I just realized it is
quite simple with QEMU. Since there is no .iso for BasicLinux to use with
QEMU, it must be expanded into a DOS directory. Instead of trying to insert
the baslin directory into a DOS harddisk image, the solution is to mount the
directory as a harddrive using the "fat:" option.
What I've done is use QEMU on Win98SE
1) to boot a MS-DOS floppy image as QEMU A:
2) use a blank floppy image as QEMU B:
3) use a directory on my C: as QEMU C:
I probably could've thrown command.com etc. into QEMU C: and booted it, but
I have many floppy boot images available.
qemu.exe -L . -m 128 -no-kqemu -net none -std-vga -boot a -fda dos.img -fdb
blank.img -hda fat:.\project -localtime
QEMU boots DOS to A:, CD C:\baslin, "boot" to use BasicLinux's boot.bat to
boot Linux using loadlin.exe.
Magically, QEMU C: has a link and is mounted in BasicLinux... (Great!)
In QEMU C:, I've got BasicLinux in baslin, moss sources, moss Linux bin,
decompressed 7zdec.
I unzipped the moss sources and moss bins. However, exiting QEMU or
rebooting Linux looses the changes. This happens whether I expand into
BasicLinux's fs.img or the QEMU C:. I added floppy QEMU B: because QEMU at
the moment only seems to save into images... I was able to mount the floppy
images in BasicLinux, although I'm not quite sure what the proper command
is. Normally, I'd use something like:
mount /dev/fd0 /tmp -t fat
mount /dev/fd0 /tmp -t vfat
However, that won't mount them for me... I also tried -t option immediately
after "mount." So, I'm using:
mount /dev/fd0 /tmp
This complains about a missing ext2 filesystem, but mounts the images
correctly...
Anyway, the environment is setup or useable. gcc -v works. I'll let you
know if/when I get back around to this, or more likely, if I make any
progress.
Rod Pemberton
Rugxulo
On Feb 2, 12:32 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:06631d19-297f-4622...@a12g2000pro.googlegroups.com...
>
> > Just try this: create a small (50 MB) HD image via QEMU-IMG,
> > "format" and "sys c:" it via FreeDOS to make it FAT, use the -hdb fat:/
> > mydir/blah QEMU option to let you read from your host OS (e.g. put the
> > BasicLinux .ZIP there as well as the MOSS Linux cross-compiler), then
> > just use normal DOS tool (e.g. DJTAR) to unpack the BasicLinux .ZIP
> > from D:\ to that HD image. Then you should be able to boot BasicLinux
> > on top of FreeDOS and then mount D:\ drive (/dev/hdb1 or whatever) in
> > Linux and "cd / ; tar xvzf /tmp/moss-0.90-bin-linux.tar.gz ; export
> > PATH=/usr/local/i386-moss/bin:$PATH" and then type "gcc -v" and see
> > what happens. (Should work. At least it did for me.)
>
> Okay, I must've been thinking way too hard... ;) I just realized it is
> quite simple with QEMU. Since there is no .iso for BasicLinux to use with
> QEMU, it must be expanded into a DOS directory. Instead of trying to insert
> the baslin directory into a DOS harddisk image, the solution is to mount the
> directory as a harddrive using the "fat:" option.
>
> What I've done is use QEMU on Win98SE
> 1) to boot a MS-DOS floppy image as QEMU A:
> 2) use a blank floppy image as QEMU B:
> 3) use a directory on my C: as QEMU C:
>
> I probably could've thrown command.com etc. into QEMU C: and booted it, but
> I have many floppy boot images available.
>
> qemu.exe -L . -m 128 -no-kqemu -net none -std-vga -boot a -fda dos.img -fdb
> blank.img -hda fat:.\project -localtime
I never bother with "-no-kqemu -net none -std-vga -localtime", and it
works fine. Just to save you some typing. ;-)
> QEMU boots DOS to A:, CD C:\baslin, "boot" to use BasicLinux's boot.bat to
> boot Linux using loadlin.exe.
>
> Magically, QEMU C: has a link and is mounted in BasicLinux... (Great!)
>
> In QEMU C:, I've got BasicLinux in baslin, moss sources, moss Linux bin,
> decompressed 7zdec.
>
> I unzipped the moss sources and moss bins. However, exiting QEMU or
> rebooting Linux looses the changes. This happens whether I expand into
> BasicLinux's fs.img or the QEMU C:. I added floppy QEMU B: because QEMU at
> the moment only seems to save into images...
Right, QEMU won't save to fat:/ (i.e. host drive), only to virtual
images (e.g. -fda floppy.img or -hda filename.img). I think it will
never support that, IIRC. Kinda a bummer. What I did was QEMU-IMG
create a blank image file, boot QEMU with FreeDOS, format that image
file (as if it was a real hard drive), then unpack BasicLinux on the
fake image, and run from there (not boot from locally since I knew it
wouldn't save changes that way). You do have to transfer files
manually via floppy images or FTP or whatever. It's a known
shortcoming of QEMU (or at least I never bothered / learned any other
way, not sure about the experimental USB support).
> I was able to mount the floppy
> images in BasicLinux, although I'm not quite sure what the proper command
> is. Normally, I'd use something like:
>
> mount /dev/fd0 /tmp -t fat
> mount /dev/fd0 /tmp -t vfat
>
> However, that won't mount them for me... I also tried -t option immediately
> after "mount." So, I'm using:
>
> mount /dev/fd0 /tmp
That looks right, so I dunno (although I do normally use "-t vfat"
also). Normally you mount to /mnt (or /mnt/floppy or whatever dir is
free, but the dir must already exist).
> Anyway, the environment is setup or useable. gcc -v works. I'll let you
> know if/when I get back around to this, or more likely, if I make any
> progress.
Note that the only reason to use that version is in case it (might)
possibly be easier to recompile with it. Good luck! (But I'm not
holding my breath.) Maybe I should try too, but it looks a bit
confusing with all those billions of little files. (I also meant to
install BasicLinux on my old DOS machine, maybe I'll hurry up and do
that.)
P.S. Okay, lemme add a few other cross-compiling links I was saving:
http://gnuwin32.sourceforge.net/packages/libgw32c.htm
"This is an implementation of a small part of GLibC, just enough to
compile most Unix programs on MS Windows. It contains functions for
passwords, process id's groups, and strings. Most are interfaces to
the MS-Windows Win32 API. Some are just dummy functions that do
nothing. "
...
Hmmm, actually all I had otherwise was just a bunch of links to GCC /
EMX / FPC cross-compiler stuff (e.g. BinUtils Win32 cross-tools from
FreePascal for various targets, various EMX DOS+OS/2 compilers +
updates, various RSX + RSXNT + RSXNTDJ + NT09D files which are
apparently very hard to find, as well as the old FPC 1.0.10 DOS+OS/2
EMX version). I guess that's not hugely relevant here, but at least I
found it interesting. ;-)
Rod Pemberton
>
[QEMU issues]
Yeah, I'll probably end up creating an harddisk image as you suggest...
copy everything to it...
> http://gnuwin32.sourceforge.net/packages/libgw32c.htm
>
> "This is an implementation of a small part of GLibC, just enough to
> compile most Unix programs on MS Windows.
It's good to know what that minimum set is. As you may recall, I've keeping
track of similar info. Although from what they listed, that minimum set
seems quite large to me... and has way too much POSIX. It's amazing to
think about the fact that they didn't have the forsight to restrict coding
their utilities using only ANSI C - except where impossible. It's a huge
waste of the potential of their codebase, i.e., not portable except to POSIX
environments.
> It contains functions for
> passwords, process id's groups, and strings. Most are interfaces to
> the MS-Windows Win32 API. Some are just dummy functions that do
> nothing. "
The conversion to Win32 API makes it useless for non-Windows use...
although it probably edited out much useless *nix code. It's likely nowhere
near ANSI C. I just can't win. Although, it could be a good starting point
for an ANSI C compileable libc, if you wanted to deal with the GPL.
"Use of LibGw32c as a separate development library is very complicated. The
most practical way is to copy the source code for the necessary functions to
your own source code and to adapt your include files and Makefiles. For some
functions you must also link with the following standard libraries: -
libole32.a - libuuid.a - libwsock32.a"
Ah, my life story... never anything to reduce work.
From the description you quoted, I would've thought it was *new* code, not
reduced glibc. And, it's GPL even though there is no license... The
smaller size is important. Who needs (another) GPL'd libc? A non-GPL'd
libc would be useful. Although, I guess if you didn't want Cygwin's .dll,
it's one more option.
> Hmmm, actually all I had otherwise was just a bunch of links to GCC /
> EMX / FPC cross-compiler stuff (e.g. BinUtils Win32 cross-tools from
> FreePascal for various targets, various EMX DOS+OS/2 compilers +
> updates, various RSX + RSXNT + RSXNTDJ + NT09D files which are
> apparently very hard to find, as well as the old FPC 1.0.10 DOS+OS/2
> EMX version). I guess that's not hugely relevant here, but at least I
> found it interesting.
I've heard of EMX, but since I don't have OS/2... useless (?). I think I
looked at that RSX stuff. I don't recall what I thought about it. I'm
unfamiliar with the other combinations.
RP
Robert Riebisch
> Right, QEMU won't save to fat:/ (i.e. host drive), only to virtual
> images (e.g. -fda floppy.img or -hda filename.img). I think it will
> never support that, IIRC. Kinda a bummer. What I did was QEMU-IMG
> create a blank image file, boot QEMU with FreeDOS, format that image
> file (as if it was a real hard drive), then unpack BasicLinux on the
> fake image, and run from there (not boot from locally since I knew it
> wouldn't save changes that way). You do have to transfer files
> manually via floppy images or FTP or whatever. It's a known
> shortcoming of QEMU (or at least I never bothered / learned any other
> way, not sure about the experimental USB support).
QEMU also supports VHD or VMDK disk images. Both, Microsoft Virtual
Server and VMware Server include tools (vhdmount.exe or
vmware-mount.exe) to mount disk images to a drive letter on your Windows
system. If you know how to unpack their setup files ... ;-)
Rugxulo
On Feb 3, 2:37 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:5a8fd366-52e8-4389...@t39g2000prh.googlegroups.com...
>
> >http://gnuwin32.sourceforge.net/packages/libgw32c.htm
>
> > "This is an implementation of a small part of GLibC, just enough to
> > compile most Unix programs on MS Windows.
>
> It's good to know what that minimum set is. As you may recall, I've keeping
> track of similar info. Although from what they listed, that minimum set
> seems quite large to me... and has way too much POSIX. It's amazing to
> think about the fact that they didn't have the forsight to restrict coding
> their utilities using only ANSI C - except where impossible. It's a huge
> waste of the potential of their codebase, i.e., not portable except to POSIX
> environments.
Windows isn't POSIX either. They've removed their POSIX subsystem in
latest versions, Interix is non-free and seems frozen (from what I've
heard), and people always whine about how they lack many functions. So
I dunno. Of course, the main point of me mentioning this is that "Hey,
somebody ported part of GLIBC, so I guess DOSEMU ain't too impossible
to host on Windows now." Then again, DOSBox CVS is supposedly improved
a fair bit now (P166 ??), but I'm not really interested in that until
final release.
> > It contains functions for
> > passwords, process id's groups, and strings. Most are interfaces to
> > the MS-Windows Win32 API. Some are just dummy functions that do
> > nothing. "
>
> The conversion to Win32 API makes it useless for non-Windows use...
> although it probably edited out much useless *nix code. It's likely nowhere
> near ANSI C. I just can't win. Although, it could be a good starting point
> for an ANSI C compileable libc, if you wanted to deal with the GPL.
There are a lot of projects that aren't as wide-reaching as GNU. Of
course, even GNU seems to hinge on "GNU/Linux" these days (thus at
cost of less support for others, if at all).
> > Hmmm, actually all I had otherwise was just a bunch of links to GCC /
> > EMX / FPC cross-compiler stuff (e.g. BinUtils Win32 cross-tools from
> > FreePascal for various targets, various EMX DOS+OS/2 compilers +
> > updates, various RSX + RSXNT + RSXNTDJ + NT09D files which are
> > apparently very hard to find, as well as the old FPC 1.0.10 DOS+OS/2
> > EMX version). I guess that's not hugely relevant here, but at least I
> > found it interesting.
>
> I've heard of EMX, but since I don't have OS/2... useless (?). I think I
> looked at that RSX stuff. I don't recall what I thought about it. I'm
> unfamiliar with the other combinations.
I've never had OS/2 either, but EMX isn't useless (although OpenWatcom
now exists and works well too), esp. since it works in both DOS and OS/
2. RSX is just the extender to work under DPMI instead of VCPI (which
most Windows hate). RSXNTDJ 1.51 lets you use DJGPP to make
"bound" .EXEs that run in either DOS (w/ RSX.EXE) or Win32 (w/
RSXNT.DLL). Actually, his RSXWIN + RSHELL lets you run EMX or RSX apps
in a Win16 GUI shell (uses less memory than standard DOS prompt).
Seems that he dropped bound support in 1.6 beta2 (which I can only
find truncated at 99% from WayBack), preferring separate DOS and
Win32 .EXEs (and using CRTDLL instead, which loosens the license a
bit). But at least 1.6 beta2 has a more recent version of RSX.EXE
(5.24) and RSXNT.DLL:
rsx exe 111,900 Feb,09,2000 06:59:32pm A...
rsxnt dll 60,416 Jan,06,2002 07:56:50pm A...
Rod Pemberton
On Feb 3, 2:37 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> find truncated at 99% from WayBack),
1) Would you like a copy?
2) Alexei Frounze on alt.os.development found the "99%" Wayback archives
were just missing the last byte. He padded with zero... Worst case, 256
tries.
So, I've got an "rsx" directory from April 05:
cc1plus.zip
nt09dbnu.zip
nt09ddev.zip
nt09dgcc.zip
nt09dobj.zip
nt09dgpp.zip
rsxrt150.zip
nt09demx.zip
rsxnt150.zip
rsxdj151.zip
rsxide2b.zip
rsx521b.zip
rsx521s.zip
rsxwin31.txt
rsxwin31.zip
rsxn141r.zip
rsxn141r.txt
rsxnt141.txt
rsxntdj1.zip
rsxnt141.zip
rsxwdk2.txt
rsxwdk2b.zip
rsxwdk2p.zip
rsxwdk2s.zip
rsxrt151.zip
rsxntdj16beta2.tar.gz
crtdll.zip
From the last Wayback archive, it seems there were two different or newer
files: rsxnt151.zip and rsxdj15.zip and a bunch removed...
25Mb .zip of above dir:
http://rapidshare.com/files/193607774/rsx.zip.html
Rod Pemberton
Rugxulo
On Feb 3, 7:20 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:6565a771-ac36-4a64...@w34g2000yqm.googlegroups.com...
> On Feb 3, 2:37 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>
> > "Rugxulo" <rugx...@gmail.com> wrote in message
>
> > [rsxntdj] 1.6 beta2 (which I can only
> > find truncated at 99% from WayBack),
>
> 1) Would you like a copy?
I downloaded it, thanks. Mainly it just seems that only older,
obsolete RSX files are available at large (i.e. "Google it" wouldn't
help here). I guess once Rainer's site disappeared in 2006 (as well as
him!) with no obvious successor, the files disappeared into the ether
(almost).
> 2) Alexei Frounze on alt.os.development found the "99%" Wayback archives
> were just missing the last byte. He padded with zero... Worst case, 256
> tries.
That seems to be true here, and the extra byte needed is a "0" for
each of the four files mentioned (coincidentally). I even downloaded
again, and it *still* truncates at 99%, which is annoying. Must be
some bug on their (WayBack) end.
> So, I've got an "rsx" directory from April 05:
>
> cc1plus.zip, nt09dbnu.zip, nt09ddev.zip, nt09dgcc.zip, nt09dobj.zip
> nt09dgpp.zip, rsxrt150.zip, nt09demx.zip, rsxnt150.zip, rsxdj151.zip
> rsxide2b.zip, rsx521b.zip, rsx521s.zip, rsxwin31.txt, rsxwin31.zip
> rsxn141r.zip, rsxn141r.txt, rsxnt141.txt, rsxntdj1.zip, rsxnt141.zip
> rsxwdk2.txt, rsxwdk2b.zip, rsxwdk2p.zip, rsxwdk2s.zip, rsxrt151.zip
> rsxntdj16beta2.tar.gz, crtdll.zip
>
> From the last Wayback archive, it seems there were two different or newer
> files: rsxnt151.zip and rsxdj15.zip and a bunch removed...
I'm not sure why you think RSXDJ15.ZIP is newer, sounds like an older
version of RSXDJ151.ZIP (which DJGPP mirrors have in /v2tk/). That's
the last version to support "bound" DOS + Win32 .EXEs (since 1.6 beta2
only seems to build Win32-only .EXEs). One example of such
"bound" .EXE is ALink (which isn't written by me, BTW, heh).
The front page mentions RSXNT151.ZIP, but it actually points to
RSX*R*T151.ZIP. Here's what it says:
http://web.archive.org/web/20061207132404/http://www.mathematik.uni-bielefeld.de/~rainer/
------------------------------------------------------------------------------------------------------------
last update: 5 Feb 2002
Latest updates: Description:
rsxide2b.zip (282 KB) RSXIDE 2.02 (supports emx, mingw32, cygwin,
palm tools)
rsxnt151.zip (401 KB) rsxnt 1.51 runtime (new binaries rsxide, rsxnt,
rsx)
Older updates:
rsxntdj16beta2.tar.gz (1,09 MB) download beta2 of rsxntdj 1.6; Win32
SDK for djgpp; with sources
crtdll.zip (78 KB) download add-on for rsxnt (emx port); headers and
libraries to use crtdll (like mingw32)
------------------------------------------------------------------------------------------------------------
In short, the only hugely useful part of that for me is the
RSXRT151.ZIP file ("RunTime" stuff with updated RSX.EXE extender and
RSXNT.DLL etc. files).
> 25Mb .zip of above dir:http://rapidshare.com/files/193607774/rsx.zip.html
It works, thanks again. So hopefully it'll stick around for 90 days so
somebody else can mirror it. ;-)
Rod Pemberton
>
> In short, the only hugely useful part of that for me is the
> RSXRT151.ZIP file ("RunTime" stuff with updated RSX.EXE extender and
> RSXNT.DLL etc. files).
>
The dpmigcc2.zip file, here, seems to be an early RSX DOS Extender and/or
DPMI host:
http://www.ida.liu.se/~TDDB80/lispsystem/CLISP/dos/
Rod Pemberton