Mail Archives: djgpp/2009/01/11/00:16:58
Hi,
On Jan 10, 5:54 pm, "Rod Pemberton" <do_not_h DOT DOT DOT AT nohavenot DOT cmm> wrote:
> "Rugxulo" <rugx DOT DOT DOT AT gmail DOT com> wrote in message
>
> news:59d15676-685a-4ad8-a43a-7715035abbaa AT f3g2000yqf DOT googlegroups DOT 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
- Raw text -