X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Rugxulo Newsgroups: comp.os.msdos.djgpp,comp.os.msdos.programmer Subject: Re: TRYING TO MAKE EXE RUN ON FRIENDS MACHINE Date: Sat, 10 Jan 2009 21:09:41 -0800 (PST) Organization: http://groups.google.com Lines: 242 Message-ID: <66b3d054-4b29-497b-aea5-dcbae71865d3@s20g2000yqh.googlegroups.com> References: <5fb78e93-bed6-46d9-85c8-a838e35b3d22 AT r36g2000prf DOT googlegroups DOT com> <9941ccce-87a6-4ace-9f78-9b15710643bd AT x8g2000yqk DOT googlegroups DOT com> <4563e62e-7382-4c6a-b986-d4c8a8ff9d47 AT i18g2000prf DOT googlegroups DOT com> <0541cc98-689c-4e6c-ae02-d6f5a1b4a9cb AT l37g2000vba DOT googlegroups DOT com> <886d17b9-399f-48ed-ac4d-45ca11d3879f AT s20g2000yqh DOT googlegroups DOT com>

<59d15676-685a-4ad8-a43a-7715035abbaa AT f3g2000yqf DOT googlegroups DOT com> NNTP-Posting-Host: 65.13.115.246 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1231650581 19986 127.0.0.1 (11 Jan 2009 05:09:41 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Sun, 11 Jan 2009 05:09:41 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: s20g2000yqh.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id n0B5F4CM001563 Reply-To: djgpp AT delorie DOT com Hi, On Jan 10, 5:54 pm, "Rod Pemberton" wrote: > "Rugxulo" 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