X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" Newsgroups: comp.os.msdos.djgpp,comp.os.msdos.programmer Subject: Re: TRYING TO MAKE EXE RUN ON FRIENDS MACHINE Date: Sat, 10 Jan 2009 18:54:44 -0500 Organization: TornevallNET - http://news.tornevall.net Lines: 123 Message-ID: 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: bb3c94a183e190d98a56b6fc0b5735d8 X-Trace: 0aed3f8920c3a3768c46b48c558feb16 X-Complaints-To: abuse AT tornevall DOT net X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 X-Complaints-Language: Spoken language is english or swedish - NOT ITALIAN, FRENCH, GERMAN OR ANY OTHER LANGUAGE! X-Newsreader: Microsoft Outlook Express 6.00.2800.1933 X-Validate-Post: http://news.tornevall.net/validate.php?trace=0aed3f8920c3a3768c46b48c558feb16 X-SpeedUI: 1505 X-Complaints-Italiano: Parlo la lingua non è italiano X-Posting-User: c1d3d0c1b6b92a0da8bd6a8e58acbe20 X-Priority: 3 X-MSMail-Priority: Normal To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Rugxulo" wrote in message news:59d15676-685a-4ad8-a43a-7715035abbaa AT f3g2000yqf DOT googlegroups DOT com... > > 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