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: Sun, 11 Jan 2009 23:26:04 -0500 Organization: TornevallNET - http://news.tornevall.net Lines: 179 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> NNTP-Posting-Host: 094ef6facd9cb21bd2c38a251b49f078 X-Trace: 28f9db0dc4aeaa716c708b434215c59f 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=28f9db0dc4aeaa716c708b434215c59f 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:4563e62e-7382-4c6a-b986-d4c8a8ff9d47 AT i18g2000prf DOT googlegroups DOT com... > On Jan 6, 5:11 am, "Rod Pemberton" wrote: > > "Rugxulo" wrote in message > > > > > 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. > 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