X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Rugxulo Newsgroups: comp.lang.misc,comp.os.msdos.djgpp Subject: Re: Seed7 2010-09-05 (very rough DJGPP port of HI.EXE) Date: Fri, 15 Oct 2010 06:57:40 -0700 (PDT) Organization: http://groups.google.com Lines: 218 Message-ID: References: <4e6805a8-8102-4a73-8fc7-6cb415f81c22 AT i5g2000yqe DOT googlegroups DOT com> <0790b8ef-672d-4260-9509-579c37e79c7a AT e20g2000vbn DOT googlegroups DOT com> <5e42f96c-c528-4671-a777-a3f0c3ad0eed AT l8g2000yql DOT googlegroups DOT com> <52ded91b-c6c9-41fb-8723-df31d6f0e29a AT p26g2000yqb DOT googlegroups DOT com> NNTP-Posting-Host: 65.13.115.246 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1287151060 5103 127.0.0.1 (15 Oct 2010 13:57:40 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Fri, 15 Oct 2010 13:57:40 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: i21g2000yqg.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.1; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.63 Safari/534.3,gzip(gfe) Bytes: 11953 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hi, (and yes I meant to cc to djgpp group also, not just followup, sorry) On Oct 15, 5:48=A0am, tm wrote: > > It is a port of the P4 Pascal compiler not Pascal_S. > All this things work, but the do not work with the > officially released Seed7. Don't hold your breath. It will take some > time. That's fine, I was just curious, not impatient. BTW, I guess you also know about Scott Moore's updating of P4 to full ISO 7185, aka P5. But I digress .... > > On Oct 12, 8:48 am, tm wrote: > > I will try to improve the next release so that fewer changes for DJGPP ar= e necessary (see below). In theory, it should be pretty easy, just disable stuff that doesn't work, and hopefully at least a vanilla interpreter (without GUI bindings, etc.) would be buildable. In practice, it takes some effort. (Thankfully DJGPP + GCC etc. does most of this for us.) > You are right, the interpreter does not need this things. The > interpreter can definitely be provided as executable. That's good, something easy to play with interactively without having to build anything. > > Of course, I would personally link statically if > > at all possible, but I realize that's not probably going to happen. > > This is going to happen when I find a way to configure the Seed7 > compiler independent of the interpreter. You probably already knew this, but the DJGPP one is indeed static. (No, I didn't use DJELF, but that exists if you're really curious. DXE3 is yet another ball of wax.) In particular, I was thinking of Linux and *BSD, where I think sometimes dynamic libs are a burden, esp. Linux with a billion semi-incompatible distros. The advantage of DJGPP should be obvious: DOS, OS/2, Win32, Linux (DOSEMU), DOSBox, QEMU, etc. But some people don't even like the "idea" of DOS, even when it works! > > TinyC/TCC works on Windows and is an extremely small download. You > > could always bundle that. > > From time to time I think over bundling Seed7 with a C compiler. > But this would IMHO lose more than it wins. Currently C is used > as platform. When a C compiler is bundled the processor is the > platform. And I dont want to maintain a C compiler on several > processors and operating systems. You shouldn't have to worry, but in reality it might be (slightly?) easier to bundle TCC. It's small and works, at least more or less. ;-) I'm just saying, if you're really concerned about compiling, that would be easier. But it's not like Cygwin is (too) hard to install either, just takes a lot longer (esp. on slow connections). Even MinGW isn't that minimal anymore. (At one time it was 15 MB minimum, I think, not sure nowadays.) EDIT: Oops, just to remind you that OpenWatcom exists too (albeit with little POSIX support, but it can't be worse than MinGW in that regard, can it?). It's not that I expect you to bundle a compiler, the interpreter alone is sufficient for most (or even all) purposes. Just it might make it easier to have an easy-to-install compiler. > > I also made a one-floppy DJGPP install (GCC > > 2.95.3) with Make, but that's probably too old. But hey, if you can > > get it working, that should be easy to bundle too. Those are much more > > "minimal" than MinGW or Cygwin. But it depends on how much POSIX you > > need / expect / want (2008? mmap?). > > mmap is used optionally and fork is not used, but some other POSIX > stuff is used. Since you made the one-floppy DJGPP install you have > probably much more knowledge about it. Doubt it! ;-) All I did there was just 7zip as much as I could cram in 1.4 MB. I think DJGPP supports (older) POSIX, circa 1992 standard, except for obvious things like fork, which most DOSes lack. But of course things like mmap (required by 2008?) don't work either. People shouldn't forget that we can live without some of these "modern" things. (Or at least nobody needed it bad enough to write their own.) For the record, it's been said that DPMI 1.0 could handle / fake mmap, but a). almost nobody fully supports DPMI 1.0, even Windows and OS/2, b). nobody has bothered writing an mmap routine for DJGPP (probably due to lack of OS support). It would probably be easier to hack CWSDPMI (if I knew how, mind you), but like I said, then it will only work in "pure" DOS (or DOSBox). Well, not sure about DOSEMU or FreeDOS-32, they probably work. And DPMIONE is freeware (closed src) at least. And HDPMI has some 1.0 stuff too. Okay, so it's not impossible, but I personally am too dumb, and volunteers are low. :- ( > When you send me results (like you did with the DJGPP port) > I can do improvements for the next release to make it easier. Not sure what results you want, you'll have to be more specific! I 7zip'd everything (very raw) for you. It was a "quick" hack. I kept at it just in the hopes that "somehow" it might actually work! And having a (mostly) working result was very good news, even for me! :-) > Is it okay to add your makefile to the next release as mk_djgpp.mak? > When I have not time to try it I can add it to the release and > mention it as experimental makefile. You can add whatever you like. It's just that there are some things to be aware of that DOS or DJGPP lack vs. Linux and Win32 (which have everything and the kitchen sink thrown in). Like I said, even MinGW isn't really "minimal" in my eyes. > > Here's my (srcs + .o files + .EXE) built with DJGPP: > > >http://drop.io/bsbuwco > >http://rapidshare.com/files/424908618/seed7-djgpp.7z > > > (if neither of those two work for you, email me) > > The first one worked. Maybe not everybody knows the .7z format (I > know it, but on my Linux system it was necessary to install 7Zip). > I did a diff to see your changes. I would've done a diff for you, but I figured an actual build (in fact, the exact same as I made) was better, temporarily, esp. with .EXE. That way you could see if it's even worth diff'ing! BTW, I figured .7z wasn't too exotic, so I wasn't worried. p7zip provides Linux binaries on its SourceForge site. I don't want to say it's "easy" to compile (G++, ugh), but it works. (Yeah, most distros don't provide GCC/G++ by default, doh.) Heck, there's a port to DJGPP too (hi Khusraw! and yes, even of 9.13, too bad nobody mirrored it for FreeDOS yet, I don't have iBiblio FTP rights or else I would've already done it). There's also 7zdecode (ANSI C, public domain!) from the LZMA SDK, which I compiled with various compilers (though I neglected Linux, mainly focused on DOS / Win32), which is much smaller / easier to build. > You obvously did symlinks for some *.s7i files from the seed7/prg > directory to the seed7/lib directory. This links are not necessary > when the file version.h contains > > =A0 #define SEED7_LIBRARY "<< insert absolute path of seed7/lib >>" Well, either Seed7's HI has to live in its own directory or you have to have a way to find the include files. Personally, I'd make it a runtime environment variable, e.g. SEED7_INCLUDE, so you could change it, instead of hardcoded. I didn't bother even checking if "make install" was available since I just assumed it wouldn't do the right thing anyways. (Normally they just do --prefix=3D/dev/env/DJDIR"). It was just easier to symlink. (Normally I would just hard copy the files, but luckily 2.04 doesn't need that, heh, saved some space. If somebody cared for 2.03p2 though ....) > In the file fil_rtl.c (function offsetSeek) you renamed the > parameter offset to ofset. Is offset predefined? To avoid future > problems with this parameter the next release will rename it to > anOffset. I don't remember, it might be. I know there was something else that I had to change from "offsetOf" to "int" so GCC wouldn't bork. And some other minor changes like that. It wasn't very professionally done, I was just hacking to see if I could shut it up so to actually build! ;-) > In the files kbd_inf.c, kbd_poll.c, scr_inf.c and trm_inf.c you > changed the line > > =A0 #include "ncurses/term.h" > > to > > =A0 #include "term.h" > > This is the job of INCL_NCURSES_TERM so the line > > =A0 #undef =A0INCL_NCURSES_TERM > > should be enough and the changes in the 4 files are unnecessary. Normally DJGPP only uses PDcurses, which I had installed, but after various errors that I didn't understand (perhaps my fault, I admit), and once I saw ncurses mentioned (Linux favorite), I found it easier to just temporarily install Blair's unofficial port. Of course, he didn't stick to conventional DJGPP package layout (no *.mft, etc), so I guess I installed it incorrectly, hence the tweaking of the files. It didn't seem correct (in my mind) to put it in yet another subdir (/ ncurses/), so I didn't. I just put the libs in /lib/ and the includes in /include/, seemed more obvious to me. But like I said, that's probably non-standard, so my bad. I just wanted to get it working, so .... > The next release will add an empty function for drwGenPointList to > the file drw_dos.c . This way your change in drw_drv.h should not > be necessary. I don't remember. It was just to stop GCC from whining, help it find what it needed (kbdGetc or whatever). It seems obvious that you always expect a GUI available, which slightly complicated things, even for the little ol' interpreter. ;-) > Many thanks for your effort. Please keep up with your work. It wasn't much, but I'll help more (if possible). I'm not a POSIX guru. I'm not able to write complex interrupt handlers. I just hack and hack and hack until GCC shuts up. Yeah, C is not my favorite language. Even all the *nix stuff kinda overcomplicates everything. Unavoidable these days. It's hard to simplify when everything is already so complex. It's just that I feel silly when something supports POSIX and GCC and doesn't work in DJGPP. It makes me wonder, "Why not?" That (blind) hope is the only reason I tried (well, and some experience building other things in the past few years). DOS might be weak, but if it runs GCC + Emacs + p7zip + Quake, how bad can it be??