Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
Rugxulo

Homepage

Usono,
15.02.2012, 16:14
 

OMF records (Developers)

Post reply

Oberon/M (direct link) 1.2 for DOS is an old 16-bit Oberon-1 compiler circa 1991. So old, in fact, that it was expected to be used with MS LINK, which at the time (MS-DOS 4.0?) came bundled with the OS. Unfortunately, it uses at least one problematic ("obsolete") OMF .OBJ record in its output: REGINT. This chokes most linkers. For various obscure reasons, I very very lightly decided to look into the matter.

If you read ftp://ftp.openwatcom.org/devel/docs/omf.pdf , you will see that the "official" (?) standard for OMF was later defined by TIS circa early '90s to be version 1.1, and it explicitly mentions how some OMF records have changed or been obsoleted. Which is annoying as this compiler requires such an old linker. Actually, I think MS LINK just ignores the REGINT record (which begs the obvious question, "why did the author bother then??").

I'm honestly not sure what 16-bit object formats exist. I think OpenWatcom uses OMF probably because of its segmentation support, which (AFAIK) other formats (ELF, COFF) don't support. It's a bit complex and seemingly designed for quick two-pass handling in minimal memory. If someone were to write a compiler today, I'm not sure OMF would be ideal, even with the 32-bit extensions. Perhaps a homebrew format would be simpler, dunno, but that may be wishful thinking.

Anyways, as I said, the "Main" .OBJ of a project from Oberon/M is generated with a REGINT record right before the (mandatory) MODEND, which ends the file. This chokes most linkers (except for a very few, which I don't rely upon for various minor reasons). Yesterday I whipped up a quick patch in .C (presumably portable in case of cross-compilation or patching or whatever). It seems to work, though I didn't too heavily test it.

If anybody cares, some simple feedback would be welcome as it's kinda a confusing subject.


/* HACKOMF.C -- util to patch old Oberon/M .OBJ output for some linkers */

#include <stdio.h>
#include <stdlib.h>

enum omf {
  REGINT=0x70,   /* obsolete, unsupported record to patch out */
  MAINOBJ=0x80,  /* if main object file for program */
  MODEND=0x8A,   /* always last OMF record */
  COMENT=0x88    /* replace with a harmless comment */
};

int main(int argc, char** argv) {
  int rc=EXIT_FAILURE, count=0;
  FILE* fp;
  unsigned char buf[32];

  if (argc > 1) {
    fp = fopen(argv[1],"rb+");
    if (fp == NULL) {
      fprintf(stderr,"\nCouldn't open %s !\n",argv[1]);
    }
    else {
      fseek(fp,-5L,SEEK_END);
      fread(buf,1,5,fp);
      if ((buf[0] == MODEND) && (buf[3] & MAINOBJ)) {
        fseek(fp,-21L,SEEK_END);
        fread(buf,1,21,fp);
        printf("'0x%02X' should be 0x%02X (REGINT)\n",buf[0],REGINT);
        if (buf[0] == REGINT) {
          buf[0] = COMENT;
          for (count=3; count < 15; count++) buf[count] = ' ';
          buf[15] = '\0'; /* empty chksum */
          fseek(fp,-21L,SEEK_END);
          fflush(fp);
          if (fwrite(buf,1,21,fp) == 21) {
            fflush(fp);
            printf("...patching...\n");
            rc=EXIT_SUCCESS;
          }
          else fprintf(stderr,"\nOops! Couldn't write file.\n");
        }
        else fprintf(stderr,"\nREGINT OMF record not found.\n");
      }
      else fprintf(stderr,"\nWrong OBJ detected (or already done).\n");
      fclose(fp);
    }
  }
  else fprintf(stderr,"\nNo .OBJ specified!\n");

return rc;
}

/* EOF */
rr

Homepage E-mail

Berlin, Germany,
15.02.2012, 21:09

@ Rugxulo
 

Just some research about the name "E. R. Videki"

Post reply

- Videki II Edwin R, Innovator, Tucson, AZ
- License Direct: Pennsylvania Engineers; Professional Engineer Licenses
- Edwin R Videki (1928 - 1993) Genealogy - Lady Lake, Lake County, FL, (Florida)
- ininventor:"edwin r. videki, ii" - Google Search
- Edwin Videki Raymond - REDWOOD CITY,CA | ed videki | 4+ People Finder Results
- 223 Cerrito Avenue, Sequoia, 94061 | San Francisco
- http://files.usgwarchives.net/fl/sumter/cemeteries/bushnational139.txt
- Edwin Raymond Videki, 64 . . . Civil Engineer - Orlando Sentinel

---
Forum admin
Arjay

15.02.2012, 22:08

@ rr
 

Just some research about the name "E. R. Videki"

Post reply

Below are the results of a quick bit of research I did into E.R.Videki (author of Oberon-M). His contact details for the compiler were via Tandem Computers was brought by Compaq in 1997 then HP, hence the domain is now owned by HP.

From what I could work out it would appear that long before Compaq brought Tandem Computers that he left to work at IBM. If you search for "IBM patent E. R. Videki" his name comes up quite a bit, and I noted that he mostly used "E. Videki" and this appears to be a list of his patents which lists his first name as Edwin: http://patents.justia.com/inventor/EDWINRVIDEKIII.html


Sadly a search on Edwin R. Videki resulted in the following:
"Edwin was born on November 17, 1928. Edwin died on April 12, 1993 at 65 years old."
http://www.ancientfaces.com/research/person/9874699/edwin-r-videki-profile-and-genealogy


:-(
Rugxulo

Homepage

Usono,
15.02.2012, 23:19

@ Arjay
 

Just some research about the name "E. R. Videki"

Post reply

>
> Sadly a search on Edwin R. Videki resulted in the following:
> "Edwin was born on November 17, 1928. Edwin died on April 12, 1993 at 65
> years old."
> > ">http://www.ancientfaces.com/research/person/9874699/edwin-r-videki-profile-and-genealogy
>
>
> :-(
Death is a part of life. It happens. So I wasn't that surprised. However ...

The link above (Orlando Sentinel) from rr mentions this:

> Survivors: sons, Edwin R., Morgan Hill, Calif.
And if you check OBERNM12.ZIP's README at the bottom, it says this:

> Written notes can be mailed to this address:
> P. O. Box 58
> Morgan Hill, California 95038
> U.S.A.
So I'm actually "guessing" it was his father and not him. Actually, for years I always thought 1.1 was the last version until I stumbled across 1.2 (which fixed my two main gripes, thankfully) despite me never having actually used the dang thing until recently (year or such ago). BTW, I read online somewhere that he used Turbo Pascal to make this, no huge surprise there.

BTW, there are newer versions of the Oberon language, usually Oberon-2 (added a few things, most popular dialect) and recently Oberon-07 (removed a lot, added a few, 2007-present). However, the original is still worth using, IMO.
Arjay

16.02.2012, 00:47

@ Rugxulo
 

Just some research about the name "E. R. Videki"

Post reply

> The link above (Orlando Sentinel) from rr mentions this:
> > Survivors: sons, Edwin R., Morgan Hill, Calif.
 Good catch, missed the sons line.

> And if you check OBERNM12.ZIP's README at the bottom, it says this:
> > Morgan Hill, California 95038
 I did spot but wondered if above was him, if he had moved to be with/near relatives but as above I think you may be right it could have been his father.

> until I stumbled across 1.2
 I followed your d/l link to i guess the older version?


> BTW, I read online somewhere that he used Turbo Pascal to make this,
> no huge surprise there.
 As I like looking at things in a hex editor I thought I'd check into this early on. The EXE's are certainly Borland structured, however I noted they all lack the usual Borland boiler plate and tlink version bytes (e.g. FBh, 10h, 6Ah, 72h) which were certainly in use with TP5,5.5,6.0 which were all out when he released this. I did note that SYS.OBJ contains a TASM v1.0 copyright string unlike all the other OBJ files. I did wonder if he was copying a template object file and then modifying it, so I decided to test this by moving only OC.EXE into a test directory with a test.mod file and compiling it resulted in an test.obj without complaints. So I then confirmed the OBJ creation by copying OC.EXE to a different name and modifing 2 bytes of the last of the 3 (tm) strings in OC.EXE which I guessed to be the string used on the OBJ header. My guess was right and I noted that ther modified OBJ header appeared in the resulting OBJ compiled with my quick mod version.

I also compared the header of sys.obj with the output of the test obj's and noted differences beyond the text which confirmed that the obj's are being built by the compiler rather than just modified from a builtin pre-generated.

Anyway my guess is that his compiler was probably either built with tasm but linked with ms link, or it was built with a customised version of borland pascal/c (which came with rtl source) which in this instance was modified to build the EXE's (which lack the usual pascal or C rtl bits/strings/sys vars). That said he could have used Turbo Pascal/C without the rtl source by using various tools to replace/reduce the size of the rtl which exist, however I expect the later is less likely as even harder to use than rtl src.

Anyway this is all academic but as I spent a few mins looking at the files I thought you might be vaguely interested in the above.
Arjay

15.02.2012, 22:36

@ Rugxulo
 

OMF records

Post reply

> compiler circa 1991. So old, in fact, that it was expected to be used with
> MS LINK, which at the time (MS-DOS 4.0?) came bundled with the OS.
> Unfortunately, it uses at least one problematic ("obsolete") OMF .OBJ
> record in its output: REGINT. This chokes most linkers.
Have you tried the following LINK/TLINK options?
Quote: the basic structure of both MS and Borland OBJ formats is based on the OMF format so specifying that the linker ignore the extended dictionary records (/NOE for LINK, -e for TLINK) will disable this little hassle.

via http://www.faqs.org/faqs/msdos-programmer-faq/part2/ which just happened to come back when I did a Google related search for Simtel OMF as I remembered there were a number of interesting OMF linker tools on my Simtel BBS CD's. Sadly the new "improved" simtel.net site is near enough useless now days and I couldn't find those utils quickly just now but might also be worth checking.

> For various obscure reasons, I very very lightly decided to
> look into the matter.
 Good enough reason :-)

Hope the above helps.
Rugxulo

Homepage

Usono,
15.02.2012, 23:29

@ Arjay
 

OMF records

Post reply

> > compiler circa 1991. So old, in fact, that it was expected to be used
> with
> > MS LINK, which at the time (MS-DOS 4.0?) came bundled with the OS.
> > Unfortunately, it uses at least one problematic ("obsolete") OMF .OBJ
> > record in its output: REGINT. This chokes most linkers.
>
> Have you tried the following LINK/TLINK options?
> Quote: the basic structure of both MS and Borland OBJ formats is based
> on the OMF format so specifying that the linker ignore the extended
> dictionary records (/NOE for LINK, -e for TLINK) will disable this little
> hassle.

16-bit TLINK seems to work fine. So does MS LINK (which the author seemed to prefer). The former is available in various freeware Borland releases (but can't be redistributed). The last MS LINK is actually a 32-bit PharLap .EXE and is publicly hosted on MS' FTP site, but it seems to be mostly a patch to MS VC 1.52 (last with 16-bit support), which is still commercial.

QLINK (recently GPL'd) works if you use /OMF:IGN ("ignore") but needs DPMI 1.0 (aka, DPMIONE), and it apparently doesn't play well with DOSEMU or really big RAM machines (e.g. this 6 GB behemoth).

WLINK doesn't really work, not sure why. For a single file project, it works, but something somewhere goes wrong with multiple .OBJs and it reports incompatibilities ("module out of date" or whatever, bogus def/ref internal hash key clash?).

For testing yesterday, I was actually using CC386's VALX, though it gave a few weird warnings. But it seemed to work, so I didn't complain.

I forget what others I tried. All I know is that it seems ludicrous to have so many linkers not handle the format, esp. when this compiler REALLY needs a linker. While I can see some simple compilers generating code directly, I don't think that would be 100% wise if you want to share code from the outside world. But it's obviously much harder to support a (pre?)"standard" object format (e.g. see FASM's latest postponement of Mach-O support). I naively figured I could just change 70h to 88h and it would work (and apparently did), but then I decided to read up a bit and play it a bit more "safe" just in case.

(There are other Oberon compilers but none that target 16-bit DOS, AFAICT. Color me nostalgic.)

> via
> http://www.faqs.org/faqs/msdos-programmer-faq/part2/
> which just happened to come back when I did a Google related search for
> Simtel OMF as I remembered there were a number of interesting OMF linker
> tools on my Simtel BBS CD's. Sadly the new "improved" simtel.net site is
> near enough useless now days and I couldn't find those utils quickly just
> now but might also be worth checking.
>
> > For various obscure reasons, I very very lightly decided to
> > look into the matter.
> Good enough reason :-)
>
> Hope the above helps.
I'm no linker expert, far from it, similarly for OMF or actually freakin' anything really! I didn't expect anyone to know anything (maybe Japheth, but I didn't presume to directly waste his time either). I just wanted to document my efforts in case anyone cared later on.
Arjay

16.02.2012, 01:09

@ Rugxulo
 

OMF records

Post reply

> > > compiler circa 1991. So old, in fact, that it was expected to be used
> > with
> > > MS LINK, which at the time (MS-DOS 4.0?) came bundled with the OS.
 Yup along with exe2bin, edlin and other such delights. Things started to be dumbed down with v5 when he was introduced and dosshell (yuk).

> 16-bit TLINK seems to work fine.
Which makes sense re use of Borland's tools to dev (see my separate reply).

> So does MS LINK (which the author seemed to prefer).
 Yup, as per separate reply his exe's don't appear to have been tlink'd.

> The last MS LINK is actually a 32-bit PharLap.EXE
 Interesting.

> QLINK (recently GPL'd) works if you use /OMF:IGN ("ignore") but needs DPMI
 Hmm, not familar but will check it out. Have you tried alink which may or may not support omf (i think it may) however so many linkers hard to remember,

> I forget what others I tried.
I know that feeling :)

> All I know is that it seems ludicrous to have so many linkers
> not handle the format,
 Thinking about it I wonder if it may be more to do with of possible bugs in the oberon obj files themselves, have you run them through a obj dumper?

> I decided to read up a bit and play it a bit more "safe" just in case.

> (There are other Oberon compilers but none that target 16-bit DOS, AFAICT.
> Color me nostalgic.)
 I think that's a good thing :)

> I'm no linker expert, far from it, similarly for OMF
Me neither I've written 1 16bit linker (not released) and started to add omf later but got busy with work. That was back in around 1997/98 by the time I had time again mid 00's things had moved on to the point that i though why bother working on it when the world was by then 32bit.

> or actually freakin' anything really!
Yeah right, don't put yourself down ;-)

> I just wanted to document my efforts in case anyone cared later on.
 always a good thing.
Rugxulo

Homepage

Usono,
16.02.2012, 08:00

@ Arjay
 

OMF records

Post reply

>> until I stumbled across 1.2
> I followed your d/l link to i guess the older version?
No, it was for 1.2 alright, just wanted to make clear that 1.1 seems to be more popular on some sites for dumb reasons (Simtel, Garbo).

> Anyway my guess is that his compiler was probably either built with tasm but linked
> with ms link, or it was built with a customised version of borland pascal/c (which
> came with rtl source) which in this instance was modified to build the EXE's (which
> lack the usual pascal or C rtl bits/strings/sys vars). That said he could have used
> Turbo Pascal/C without the rtl source by using various tools to replace/reduce the
> size of the rtl which exist, however I expect the later is less likely as even
> harder to use than rtl src.
Anything's possible. Perhaps he used a lot of inline code bits or binary patched it, who knows.

> Anyway this is all academic but as I spent a few mins looking at the files I thought
> you might be vaguely interested in the above.
Definitely interested but don't know the answer. There was a post on the 'Net somewhere once where someone explicitly said something like he had written it in Turbo Pascal, but I can't find it now. :-/

> > > > compiler circa 1991. So old, in fact, that it was expected to be
> used
> > > with
> > > > MS LINK, which at the time (MS-DOS 4.0?) came bundled with the OS.
> Yup along with exe2bin, edlin and other such delights. Things started to
> be dumbed down with v5 when he was introduced and dosshell (yuk).
I don't know why they ever removed some of that stuff later on. I don't understand companies that give you downgrades with impunity.

> > QLINK (recently GPL'd) works if you use /OMF:IGN ("ignore") but needs
> DPMI
> Hmm, not familar but will check it out. Have you tried alink which may or
> may not support omf (i think it may) however so many linkers hard to
> remember,
QLINK DPMIONE 386SWAT

I think I did try ALINK (though perhaps not 1.7 beta, latest?), but it also didn't work. Frustrating.

> > All I know is that it seems ludicrous to have so many linkers
> > not handle the format,
> Thinking about it I wonder if it may be more to do with of possible bugs in
> the oberon obj files themselves, have you run them through a obj dumper?
Briefly, barely, yes, (e.g. OpenWatcom's DMPOBJ.EXE), but it didn't show anything obvious. Most linkers do indeed mention that they choke on the 70H record (aka, "obsolete" REGINT). Frustrating that somebody thought it was wise to let "standard" TIS 1.1 linkers choke on pre-existing OMF formats. Again, another downgrade for no reason.

> > (There are other Oberon compilers but none that target 16-bit DOS,
> AFAICT.
> > Color me nostalgic.)
> I think that's a good thing :)
I know of a 286 shareware one, Edipar, but none others for 16-bit. The original Oberon was on a Ceres machine (NS32032), aka 32-bit, in 1986.

I know general-purpose programming languages are supposed to be neutral towards hardware, but let's face it, most really don't care (anymore) for 16-bit. (Now, Modula-2 was explicitly implemented on 16-bit machines at the time, hence the need for CARDINAL as memory was tight, which Oberon removed since generally INTEGER is "big enough" these days.) Again, a lot of people seem to indicate that 16-bit is dead or useless and hardware seems to mostly agree with that. But it just feels sloppy to me.

Two's compliment, ASCII, little endian, 32-bit regs, 8-bit bytes, flat memory model, FPU always present, [un]aligned memory access, Unicode, threads, garbage collection, LFNs, POSIX support ... how many more assumptions can we make without looking foolish??

> > I'm no linker expert, far from it, similarly for OMF
> Me neither I've written 1 16bit linker (not released) and started to add
> omf later but got busy with work. That was back in around 1997/98 by the
> time I had time again mid 00's things had moved on to the point that i
> though why bother working on it when the world was by then 32bit.
GCC and Linux never properly supported 16-bit. And obviously once WinNT became mainstream, MS didn't care either. It's sad, really, that 16-bit is considered a dirty word. I'm afraid that 32-bit will one day be considered the same thing due to similar 64-bit arrogance. Why does everything have to be a pissing contest??

> > or actually freakin' anything really!
> Yeah right, don't put yourself down ;-)
I just want to make it clear that I don't think my hacks are too useful or important so that nobody misunderstands. It's all I've got, take it or leave it. ;-)
rr

Homepage E-mail

Berlin, Germany,
16.02.2012, 09:51

@ Rugxulo
 

OMF records

Post reply

> > Anyway my guess is that his compiler was probably either built with tasm
> but linked
> > with ms link, or it was built with a customised version of borland
> pascal/c (which
> > came with rtl source) which in this instance was modified to build the
> EXE's (which
> > lack the usual pascal or C rtl bits/strings/sys vars). That said he could
> have used
> > Turbo Pascal/C without the rtl source by using various tools to
> replace/reduce the
> > size of the rtl which exist, however I expect the later is less likely as
> even
> > harder to use than rtl src.
>
> Anything's possible. Perhaps he used a lot of inline code bits or binary
> patched it, who knows.
GetEXETyp 2.60 and WComp 2.01 both say Turbo Pascal 5 for OC.EXE.

---
Forum admin
Arjay

16.02.2012, 21:37

@ rr
 

OMF records

Post reply

> GetEXETyp 2.60 and WComp 2.01 both say Turbo Pascal 5 for OC.EXE.
Thanks as a quick TRiD via virustotal yesterday failed to ID the file. TRiD seems to work better locally IMHO but I was on a different box.
marcov

18.02.2012, 17:16

@ Rugxulo
 

OMF records

Post reply

> Two's compliment, ASCII, little endian, 32-bit regs, 8-bit bytes, flat
> memory model, FPU always present, [un]aligned memory access, Unicode,
> threads, garbage collection, LFNs, POSIX support ... how many more
> assumptions can we make without looking foolish??
Till somebody either supports otherwise, or pays people to do.

Apparently nobody was ever interested in a truly free 16-bit linker. Since then they would have written one.
Rugxulo

Homepage

Usono,
18.02.2012, 17:32
(edited by Rugxulo, 18.02.2012, 17:42)

@ marcov
 

OMF records

Post reply

> > Two's compliment, ASCII, little endian, 32-bit regs, 8-bit bytes, flat
> > memory model, FPU always present, [un]aligned memory access, Unicode,
> > threads, garbage collection, LFNs, POSIX support ... how many more
> > assumptions can we make without looking foolish??
>
> Till somebody either supports otherwise, or pays people to do.
>
> Apparently nobody was ever interested in a truly free 16-bit linker. Since
> then they would have written one.
BCC/Dev86's LD86 (a.out variant) doesn't count? But I digress ... nobody in "modern" Linux, *BSD, or Windows cares about 16-bit, so they don't use it.

There are plenty of freeware or free/libre linkers for DOS (ALINK, VALX, WLINK), but, as mentioned, we're dealing with various somewhat incompatible variants: Intel, MS, Borland, TIS, etc. The 32-bit extensions (from MS, Borland, others??) to OMF came much later than the original format and seem to be less widely supported in some cases. As mentioned, OpenWatcom uses OMF for various obscure reasons (mostly historic), e.g. even on Win32 (though not Linux, obviously), similar to older Borland Win32 stuff. But obviously MS uses PE/COFF, DJGPP uses "plain" COFF, AIX uses XCOFF, Ultrix and Tru64 (and VMS?) used ECOFF, Mac OS X uses Mach-O, *BSD used to use a.outb, etc. etc. etc.

There are several other Oberon compilers, see my other (Wirth birthday) thread, mostly all 32-bit, so I don't "need" Oberon/M, just messing around with it because it's tiny and seems to work fairly well for what it does.
Rugxulo

Homepage

Usono,
18.02.2012, 17:54

@ Rugxulo
 

OMF records

Post reply

> > Apparently nobody was ever interested in a truly free 16-bit linker.
> Since
> > then they would have written one.
It's a big world, so unless there is a big organization or movement (and not just random hackers like us), nothing big will get done, or at least if it does, nobody will know about it (less publicized, hidden away, disappears). This is how it is with "niche" software.

And now I remember that DJ Delorie had started work on a 16-bit linker many years ago (1997?). Of course, it's written in C++, presumably for DJGPP. For laughs, I compiled it again a few years ago (DJGPP 2.03p2, G++ 2.95.3) but really never used it as it was quite incomplete ("alpha" quality).

Anyways, I just now tried it. It must not like that damn REGINT (70h) record because that borks it, but with HACKOMF, it actually works! I'm surprised. Granted, I wouldn't be surprised if more bugs show up. He never finished it, and I'd be almost scared to use it. But at least in this wimpy case, it seems to work.

EDIT: More boring trivia. I tried ALINK (EMX/RSX compile) yesterday, doesn't work, dumps core (file).
marcov

19.02.2012, 16:47

@ Rugxulo
 

OMF records

Post reply

> > > Apparently nobody was ever interested in a truly free 16-bit linker.
> > Since
> > > then they would have written one.
>
> It's a big world, so unless there is a big organization or movement (and
> not just random hackers like us)
Nonsense. A simple compiler+linker is not rocket science, and can be easily done by a handful of hobbyists. It won't be top of the bill performance, but that doesn't really matter either.

If you make the toolchain itself 32-bit (but targeting 16-bit), the generated code might actually be quite decent since you don't have the same memory and speed constraints the original 16-bit compiler developers had.

> nothing big will get done, or at least if
> it does, nobody will know about it (less publicized, hidden away,
> disappears). This is how it is with "niche" software.
It is not a niche problem. Amiga, C=64 and OS/2 communities do get things done. Dos not.

Ask yourself why. Maybe because most of the remaining Dosers are there mainly because of inertia, rather than choice.


>... Anyways, I just now tried it.

> ... record because that borks it, but with HACKOMF, it actually works!
> ... ALINK (EMX/RSX compile) yesterday,
> doesn't work, dumps core (file).
And the smart shopping and patching goes on :-)
RayeR

Homepage

CZ,
19.02.2012, 17:19

@ marcov
 

OMF records

Post reply

> Ask yourself why. Maybe because most of the remaining Dosers are there
> mainly because of inertia, rather than choice.
Yes, it's interesting how much older platforms like C64 or Amiga have a lot of hardcore fans that still produce new SW and also improve HW. Maybe it's because it had multimedia features in times when DOS had just a bare commandline so creative people was attracted to it much more than to PC. Also this platforms has advantage in simple and unified hardware (very well documented) that makes same limitations for all users but makes programming much more simple than on PC where you have spreaded tons of incompatible HW and you want to run your progam from 386 to core i7... But regardless that most of DOS users moved to windows because there was quite good continuity of developed applications so they could forgot DOS. Except some special cases of special DOS SW that has not replacement for windows but their users leave DOS system as is because it simply works and they don't need do any development. And there left only a 0,00...% od users who use DOS just for fun, using theirs favorite old apps/games or learning system programming...

---
DOS gives me freedom to unlimited HW access.
marcov

20.02.2012, 10:33

@ RayeR
 

OMF records

Post reply

> > Ask yourself why. Maybe because most of the remaining Dosers are there
> > mainly because of inertia, rather than choice.
>
> Yes, it's interesting how much older platforms like C64 or Amiga have a lot
> of hardcore fans that still produce new SW and also improve HW. Maybe it's
> because it had multimedia features in times when DOS had just a bare
> commandline so creative people was attracted to it much more than to PC.
My bet is that the break was more definitive. I think Dos went out of favour only slowly, bit by bit, failing to give off that significant "we have to do something or it is dead" trigger.

And of course Dos was the first major computer platform that droves of people only used because of work.

> Also this platforms has advantage in simple and unified hardware (very well
> documented) that makes same limitations for all users but makes programming
> much more simple than on PC where you have spreaded tons of incompatible HW
> and you want to run your progam from 386 to core i7...

Somewhat. But I'm not so sure that that is it. E.g. Mac (68k, another such legacy group) and Amiga has internally several major revisions too, that are technically as far apart as 8086-only dos and a modern 32-bit Linux environment. And they have funky addons like CPU replacements etc.

> But regardless that>
> most of DOS users moved to windows because there was quite good continuity
> of developed applications so they could forgot DOS.

Well, and of course that the bulk wasn't on Dos as a hobby. But for that the Dos cloud was magnitudes larger, and the remaining group of faithful should still be larger than the Amiga etc groups.

But somehow they never organized and start working.

FreeDOS is a notable exception. DJGPP could be, but I'm not really sure it counts since it only gets some maintenance, and the bulk being done in DOS' heydays, not after.

> Except some special
> cases of special DOS SW that has not replacement for windows but their
> users leave DOS system as is because it simply works and they don't need do
> any development.

That goes for the Amiga group too. They don't really "need" that too. Even stronger for the Mac groups since they had a binary emulation on their next platform.

> And there left only a 0,00...% od users who use DOS just
> for fun, using theirs favorite old apps/games or learning system
> programming...
But I think in absolute numbers they were larger than the Amiga crowd.
Rugxulo

Homepage

Usono,
19.02.2012, 21:33

@ marcov
 

OMF records

Post reply

> Nonsense. A simple compiler+linker is not rocket science, and can be easily
> done by a handful of hobbyists. It won't be top of the bill performance,
> but that doesn't really matter either.
Define "simple". FALSE? PL/0? Oberon/0? The latter, at least, uses interfaces that are OberonOS-specific and are lacking in almost all "hosted" Oberon compilers. And I wouldn't call any of those super simple. Sure, a few of us could whip something together in six months, but it would probably leave a lot to be desired, to say the least.

> If you make the toolchain itself 32-bit (but targeting 16-bit), the
> generated code might actually be quite decent since you don't have the same
> memory and speed constraints the original 16-bit compiler developers had.
No. 16-bit vs. 32-bit has nothing to do with speed or capabilities. It's only code size and memory. 640 kb really should be enough to write a decent compiler. Heck, Wirth's ARM compiler for 32-bit OberonSA (-07 variant?) is only 61 kb. Granted, I have no idea what form of linking or OS support is also needed. But I heavily suspect a "decent" DOS compiler could easily fit in 200 kb or less. Well, there are many pre-existing that fit the bill and accomplished a lot, so I'm not exactly blindly guessing here.

> It is not a niche problem. Amiga, C=64 and OS/2 communities do get things
> done. Dos not.

AROS lacks memory protection and can't run legacy apps since it's x86 based. How is that better than DOS? C64 only has 64 kb of RAM. How is that better? There is no free/libre OS/2, how is that better? So FreeDOS trumps them all. Sure, they have a niche, but I'd hardly say they're "more" successful!

Besides, honestly, DOS is a family, not a single platform. Perhaps that's too much fragmentation. But stuff still gets done. Granted, some people prefer newer things. (BTW, speaking of that, shouldn't you be busy porting Lazarus to WinRT/Metro? Quit wasting your time here, Win8 just got a new logo! Feb. 29 preview, baby! [zzzzzzz....])

> Ask yourself why. Maybe because most of the remaining Dosers are there
> mainly because of inertia, rather than choice.
It's hardly inertia. Software isn't easy to rewrite. It's not for nothing that GCC is still popular, it works (less than ideal, but it still works nonetheless). Similarly why 2012's x86 cpus still supports 1978's 8086 instructions and real mode.

> >... Anyways, I just now tried it.
>
> > ... record because that borks it, but with HACKOMF, it actually works!
> > ... ALINK (EMX/RSX compile) yesterday,
> > doesn't work, dumps core (file).
>
> And the smart shopping and patching goes on :-)
Yes, I should just use FPC on everything 100% of the time. (BTW, wasn't there some unfinished work on an Oberon frontend in a forked FPC from somebody?? Well tell him to hurry up, heh.)

P.S. Oxford Oberon no longer (easily?) builds for DJGPP, and OO2C at one time privately built but isn't easy (or at least I never figured it out). This is more due to developers not bothering than me! It used to work, it just doesn't anymore. That is frustrating. :-(
marcov

20.02.2012, 18:23

@ Rugxulo
 

OMF records

Post reply

> > Nonsense. A simple compiler+linker is not rocket science, and can be
> easily
> > done by a handful of hobbyists. It won't be top of the bill performance,
> > but that doesn't really matter either.
>
> Define "simple". FALSE? PL/0? Oberon/0?
For any somewhat normal procedural or OOP language. You can try to find extreme cases of course, but that doesn't really say anything.


> > If you make the toolchain itself 32-bit (but targeting 16-bit), the
> > generated code might actually be quite decent since you don't have the
> same
> > memory and speed constraints the original 16-bit compiler developers
> had.
>
> No. 16-bit vs. 32-bit has nothing to do with speed or capabilities.

Please read the actual quote before replying. It was about development speed, not execution speed.

In other words, how much of a compiler can you whip up in a certain amount of time, if you can use a fairly modern 32/64-bit toolchain with linear memory, and don't care about speedy compilation on anything less than 1GHz.

> It's only code size and memory.
> 640 kb really should be enough to write a decent
> compiler.

It is not. Compilers have a relative heavy use of memory, and with global (whole program) optimization slowly becoming the norm, this gets only more important.

> Heck, Wirth's ARM compiler for 32-bit OberonSA (-07 variant?) is
> only 61 kb. Granted, I have no idea what form of linking or OS support is
> also needed.

Minimal language, minimal compiler. God knows how much effort. Irrelevant.

> But I heavily suspect a "decent" DOS compiler could easily fit
> in 200 kb or less. Well, there are many pre-existing that fit the bill and
> accomplished a lot, so I'm not exactly blindly guessing here.
I know. And from some I also know how much work it was.

> > It is not a niche problem. Amiga, C=64 and OS/2 communities do get
> things
> > done. Dos not.
>
> AROS lacks memory protection and can't run legacy apps since it's x86
> based. How is that better than DOS?

Who cares?

> C64 only has 64 kb of RAM. How is that
> better?

Again, who carez? THeir communities are vibrant and can keep up their belt, and actually get own hardware designs of the ground now and then (remember Pegasos?)

> There is no free/libre OS/2, how is that better?

Free/libre OS, and a community that can keep their own belt up, is something different. I was talking about the second, not the first.

> So FreeDOS trumps
> them all.

Well, I couldn't get 1.1 to install, so leave the trumps away ;-)
It couldn't find the cdrom it booted from :-)

> Besides, honestly, DOS is a family, not a single platform.

That is certainly one of the problems. But e.g. Amiga is also fragmented.

> But stuff still gets done. Granted, some people
> prefer newer things.

If it was, freedos would have superseded them all by now, based on an own dos-only toolchain.

> (BTW, speaking of that, shouldn't you be busy porting
> Lazarus to WinRT/Metro?

No. You still don't get the base premise of this subthread. One is supposed to develop for what you use. I don't have winrt, and don't plan to use winrt (IOW program for MS' app store), just as I don't program for Apple's.

> > Ask yourself why. Maybe because most of the remaining Dosers are there
> > mainly because of inertia, rather than choice.
>
> It's hardly inertia. Software isn't easy to rewrite.
Why does nearly every niche community then have more to show for it than Dos? Even though the total installed base and commercial relevance of Dos in its heyday was larger than of any of the others?

> It's not for nothing
> that GCC is still popular, it works (less than ideal, but it still works
> nonetheless). Similarly why 2012's x86 cpus still supports 1978's 8086
> instructions and real mode.
It's not about all others being perfect, it is about Dos not even being average.

> > And the smart shopping and patching goes on :-)
>
> Yes, I should just use FPC on everything 100% of the time.
Of course! Have I ever said anything else? :-D

> (BTW, wasn't
> there some unfinished work on an Oberon frontend in a forked FPC from
> somebody?? Well tell him to hurry up, heh.)
Not that I know. Afaik there is only the promise that I'll make a FPC based M2 compiler myself when I win the lottery :-)

As said in the other part of the thread, I never cared much for either M3 or Oberon. At least for normal usage, they might have been great experiments in the past.
marcov

19.02.2012, 16:43

@ Rugxulo
 

OMF records

Post reply

> > Apparently nobody was ever interested in a truly free 16-bit linker.
> Since
> > then they would have written one.
>
> BCC/Dev86's LD86 (a.out variant) doesn't count? But I digress ... nobody in
> "modern" Linux, *BSD, or Windows cares about 16-bit, so they don't use it.
Nobody outside those cares too, or there would be a well maintained 16-bit open source stack.

It is not "them" that are failing, it is you, the users of such things.

> The 32-bit extensions (from MS,
> Borland, others??) to OMF came much later than the original format and seem
> to be less widely supported in some cases.
OMF is afaik quite adhoc and poorly standarized, one of the reasons the unix formats (coff, elf) won out. a.out is also very simplistic, and can be seen as an unix counterpart of omf.

> similar to older Borland Win32 stuff.
I'm not sure what modern Embarcadero/Borland stuff uses. I haven't investigated, but their debug info is still called "Topview" which is afaik the (originally intel) debugging format for OMF.

> But
> obviously MS uses PE/COFF, DJGPP uses "plain" COFF, AIX uses XCOFF, Ultrix
> and Tru64 (and VMS?) used ECOFF, Mac OS X uses Mach-O, *BSD used to use
> a.outb, etc. etc. etc.
a.out/coff/ELF are the successive unix formats. Mach-O comes from Next.

> There are several other Oberon compilers, see my other (Wirth birthday)
> thread, mostly all 32-bit, so I don't "need" Oberon/M, just messing around
> with it because it's tiny and seems to work fairly well for what it does.
That's the problem, and my point exactly. Everybody is only messing around on 16-bit, and trying to apply bandaids and do some smartshopping (often on murky legal grounds) to keep stuff running.

Probably we'll have this same discussion in 2020 again, and then there still won't be an open source 16-bit toolchain.
Rugxulo

Homepage

Usono,
19.02.2012, 21:15

@ marcov
 

OMF records

Post reply

> Nobody outside those cares too, or there would be a well maintained 16-bit
> open source stack.
There already is: OpenWatcom (used by FreeDOS kernel and separately in embedded use [Wilton Helm, 186, no OS]), but that's C/C++, not Oberon.

If you check here, C has 25%, C++ has 9%, Pascal has almost 2% and Oberon only 0.2% and Modula-2 only 0.12%. Doesn't mean they are bad, just less popular.

We're talking several different things here. There are plenty of pre-existing things that support 16-bit that are "good enough" to not have to rewrite or patch anything. But they don't necessarily offer the same host or target OS, memory model, object format, or even (for existing code) language frontends, etc.

> It is not "them" that are failing, it is you, the users of such things.
It's hardly my fault that OMF has changed over the years or that compatible tools vary in quality and licensing.

> OMF is afaik quite adhoc and poorly standarized, one of the reasons the
> unix formats (coff, elf) won out. a.out is also very simplistic, and can
> be seen as an unix counterpart of omf.
It's standardized, just nobody cares because they "moved on" to newer, shinier things. Doesn't mean either is better or worse, it's just some are more popular than others. Like I said, I honestly don't know whether a from-scratch compiler would be wiser to use OMF for interoperability with pre-existing code or better to just roll their own format.

And for the record, *nix weenies hate a.out and COFF for being old and badly spec'd, but praise the newer ELF as only thing worth supporting. I think even GCC has (mostly) given up on older stuff with only minimal support in BinUtils for "older" formats. This is not (barely) based upon technical merit but more on personal preference or political reasoning. (Though indeed, "inertia" plays a part too as nobody wants to heavily mess with the backends. "Thar be dragons.") Before you whine that DOS uses old formats, go get WinNT and Mac OS X to both switch to ELF, then we'll talk. Or is it all "inertia" for them too?

> That's the problem, and my point exactly. Everybody is only messing around
> on 16-bit, and trying to apply bandaids and do some smartshopping (often on
> murky legal grounds) to keep stuff running.

I'd rather not install Oberon OS just to learn Oberon. Besides, it would be much harder to distribute the code as it'd be too heavily reliant on the OS. But yeah, most Oberon compilers lack a standard set of libs. But I don't see how you take issue with patches to pre-existing stuff. I don't see what your point is here. If it works, it works, even if it needs a few patches.

> Probably we'll have this same discussion in 2020 again, and then there
> still won't be an open source 16-bit toolchain.
So what? It's not me whining, I'm at least trying to partially get something to work instead of throwing it away. If you don't like it, fine, but I fail to see the virtue in discarding software and decrying everything that is legacy-based. It's almost like you expect me to roll my own OS, compiler, etc. Surely that's not an easy task. It's almost always easier to adapt pre-existing OSes and tools than start from scratch.
marcov

20.02.2012, 10:54

@ Rugxulo
 

OMF records

Post reply

> > Nobody outside those cares too, or there would be a well maintained
> 16-bit
> > open source stack.
>
> There already is: OpenWatcom (used by FreeDOS kernel and separately in
> embedded use [Wilton Helm, 186, no OS]), but that's C/C++, not Oberon.
Then that is the direction. Start retargeting the Oberon to use that toolchain as much as possible.

> If you check here, C has 25%,
> C++ has 9%, Pascal has almost 2% and Oberon only 0.2% and Modula-2 only
> 0.12%. Doesn't mean they are bad, just less popular.
Well, no discussion that Pascal/m2 is not bad :-D

M3/Oberon is a bit more difficult. Some people rave about it, but for me it went too far. OTOH that is based on very old experiences (before I was OOP schooled), so that might be out of whack.

I don't care much about stats like sf.net where a PHP CMS skin counts as much as 6million lines FPC/Lazarus project.

> We're talking several different things here. There are plenty of
> pre-existing things that support 16-bit that are "good enough" to not have
> to rewrite or patch anything.

I have my doubts there. Good enough is always something that is temporary or short term.

> But they don't necessarily offer the same
> host or target OS, memory model, object format, or even (for existing code)
> language frontends, etc.
True. And that is something to be expected from an own toolchain. Something you can attach to and add support for that memory model, object format etc.

But maybe that is the solution? Start adding relevant OMF support to the above watcom linker?

> > It is not "them" that are failing, it is you, the users of such things.
>
> It's hardly my fault that OMF has changed over the years or that compatible
> tools vary in quality and licensing.
I react to your repeated statements about the 32/64-bit open source crowd
not caring. It is not their task. It is the task of the 16-bit users themselves, and them alone.

> > OMF is afaik quite adhoc and poorly standarized, one of the reasons the
> > unix formats (coff, elf) won out. a.out is also very simplistic, and
> can
> > be seen as an unix counterpart of omf.
>
> It's standardized, just nobody cares because they "moved on" to newer,
> shinier things. Doesn't mean either is better or worse,

You should go into politics :-)

> more popular than others. Like I said, I honestly don't know whether a
> from-scratch compiler would be wiser to use OMF for interoperability with
> pre-existing code or better to just roll their own format.
Well, I guess that is the other solution, retarget the Oberon beast then.

> And for the record, *nix weenies hate a.out and COFF for being old and
> badly spec'd, but praise the newer ELF as only thing worth supporting.
True. Coff would be dead if it wasn't for Windows supporting derivates. But that is a decision taken already in the 1997 timeframe, hardly new.

> I think even GCC has (mostly) given up on older stuff with only minimal
> support in BinUtils for "older" formats. This is not (barely) based upon
> technical merit but more on personal preference or political reasoning.
Personally, I think because of zero activity.

> Before you whine that DOS uses old
> formats, go get WinNT and Mac OS X to both switch to ELF, then we'll talk.
> Or is it all "inertia" for them too?
Yes of course. Both chose the format in the early to mid nineties (Next is '94-95 in mach-o's case, NT also from that timeframe).

The point is that as long as people are willing to work on something it is not dead. But that is the problem with Dos. The bulk are users, not makers, at least in the programming tools department.

> I'd rather not install Oberon OS just to learn Oberon.

IIRC there was an Oberon environment that ran on top of Dos? Called "SYSTEM" or something.

Doesn't produce Oberon binaries for use outside that environment, but if learning is the only reason? SPecially since one of the charms of Oberon was the integration with an OOP OS.

> Besides, it would be
> much harder to distribute the code as it'd be too heavily reliant on the
> OS. But yeah, most Oberon compilers lack a standard set of libs. But I
> don't see how you take issue with patches to pre-existing stuff. I don't
> see what your point is here. If it works, it works, even if it needs a few
> patches.
Oberon was not just a language afaik. It was a complete environment, including an OS that functioned as an OOP store.

> > Probably we'll have this same discussion in 2020 again, and then there
> > still won't be an open source 16-bit toolchain.
>
> So what? It's not me whining,

Please :-) Everytime you can't find something it is the old "Linux/BSD/blabla don't care" Calimero argument. And that is usually my trigger :)

> I'm at least trying to partially get
> something to work instead of throwing it away. If you don't like it, fine,
> but I fail to see the virtue in discarding software and decrying everything
> that is legacy-based. It's almost like you expect me to roll my own OS,
No. I'm expecting you to start working on creation of the tools you miss, instead of constantly trying to dig into aeons old dirt in the home it magically already exist, and if you fail whine that "they just don't care".

In every message of yours, the sentiment that everybody somehow unfairly treated Dos oozes out. But if there is something at fault, it is the remaining Dos users themselves that are at fault. Not the "others".
Rugxulo

Homepage

Usono,
20.02.2012, 17:50

@ marcov
 

OMF records

Post reply

> Well, no discussion that Pascal/m2 is not bad :-D
>
> M3/Oberon is a bit more difficult. Some people rave about it, but for me it
> went too far. OTOH that is based on very old experiences (before I was OOP
> schooled), so that might be out of whack.
Modula-3 is pretty cool, but it's main advantages (OOP, generics, exceptions, threads, garbage collection) have all been taken over (literally) by Java, Python, C#. Others later gained similar features (Ada95, C++98, Delphi).

Oberon is nice but probably too minimal for most people as it lacks generics, threads, exceptions, and sometimes implementations lack garbage collection too.

In other words, there's a lot of competing languages with similar features, so there is less reason to try alternatives.

> I don't care much about stats like sf.net where a PHP CMS skin counts as
> much as 6million lines FPC/Lazarus project.
I know, 90% of statistics are made up. And I don't count stupid web crapola either, but it's not my chart. It's just a (very) rough guess at what people use. For sure, we know GNU prefers (POSIX) C over pretty much everything else.

> But maybe that is the solution? Start adding relevant OMF support to the
> above watcom linker?
As mentioned, it has support, but obviously there are some hidden quirks that need to be ironed out. WLINK is less of a generic OMF linker and more of a "this is what our compiler uses" thing.

> > It's hardly my fault that OMF has changed over the years or that
> compatible
> > tools vary in quality and licensing.
>
> I react to your repeated statements about the 32/64-bit open source crowd
> not caring. It is not their task. It is the task of the 16-bit users
> themselves, and them alone.

Specifically, I meant several things here:

* Their OSes never supported 16-bit (or at least not recently or directly, e.g. Win64)
* They never used or needed OMF, even the 32-bit extensions
* They don't care about binary compatibility, esp. with other OSes
* They nowadays focus more on C/C++ (POSIX) or C#/Java, etc.

I didn't mean they have to support 16-bit, just that they don't, for various reasons. (Though Windows should have no good excuse, but sigh, lost cause.)

> > [OMF is] standardized, just nobody cares because they "moved on" to newer,
> > shinier things. Doesn't mean either is better or worse,
>
> You should go into politics :-)
Face it, the native preferred format of Win9x/NT was PE/COFF. Presumably some toolsets only used OMF because it was good enough and were able to reuse pre-existing tools. That's normal, nobody rewrites everything from scratch.

> > And for the record, *nix weenies hate a.out and COFF for being old and
> > badly spec'd, but praise the newer ELF as only thing worth supporting.
>
> True. Coff would be dead if it wasn't for Windows supporting derivates. But
> that is a decision taken already in the 1997 timeframe, hardly new.
COFF has a variety of (minor?) problems, hence a few weird extensions to it have been done over the years. DJGPP (and EMX and original Linux) all used a.out originally. Supposedly DJGPP switched to COFF for various reasons (1992?) because it was "best at the time" (pre-existing BinUtils support??). I can only guess WinNT chose it due to Cutler's VMS (ECOFF??) history. Linux switched to ELF for better .so support (among other things, e.g. debugging, better C++ handling, etc).

> > I think even GCC has (mostly) given up on older stuff with only minimal
> > support in BinUtils for "older" formats. This is not (barely) based upon
> > technical merit but more on personal preference or political reasoning.
>
> Personally, I think because of zero activity.
I don't know, you never know with them (weird political decisions), but four of their seven "top tier" platforms for GCC 4.7.0 are Linux (presumably ELF) for various architectures. See here. And they already removed "generic" COFF and such things a while ago.

> The point is that as long as people are willing to work on something it is
> not dead. But that is the problem with Dos. The bulk are users, not makers,
> at least in the programming tools department.
Windows just buys whatever tech they need. *nix just copies Linux (or POSIX standard), no brainer, esp. with commercial support from all the weird hardware makers out there.

> > I'd rather not install Oberon OS just to learn Oberon.
>
> IIRC there was an Oberon environment that ran on top of Dos? Called
> "SYSTEM" or something.
Last updated in 1999 or 2001 or such. You really think it'll work on modern machines? In case you didn't already know, a lot of things break because of bad assumptions (esp. re: memory handling). I could be wrong, but I'm highly skeptical. However, I don't see how patching that is somehow superior to patching this (Oberon-M).

> Doesn't produce Oberon binaries for use outside that environment, but if
> learning is the only reason? SPecially since one of the charms of Oberon
> was the integration with an OOP OS.
The whole point (to me) is to see what I can do portably, and I didn't lose my interest in DOS. So I want something that (also) works here. I don't want "yet another" Linux/Win/Mac only tool.

> Oberon was not just a language afaik. It was a complete environment,
> including an OS that functioned as an OOP store.
Well, obviously if Wirth can target it to ARM, it doesn't need the fancy OS.

> > > Probably we'll have this same discussion in 2020 again, and then there
> > > still won't be an open source 16-bit toolchain.
> >
> > So what? It's not me whining,
>
> Please :-) Everytime you can't find something it is the old
> "Linux/BSD/blabla don't care" Calimero argument. And that is usually my
> trigger :)
They don't care, they openly admit such. It's not just a passive disinterest (although that's mostly true), it's downright refusal to help with anything outside of their narrow view of the software world.

> > I'm at least trying to partially get
> > something to work instead of throwing it away. If you don't like it,
> fine,
> > but I fail to see the virtue in discarding software and decrying
> everything
> > that is legacy-based. It's almost like you expect me to roll my own OS,
>
> No. I'm expecting you to start working on creation of the tools you miss,
> instead of constantly trying to dig into aeons old dirt in the home it
> magically already exist, and if you fail whine that "they just don't
> care".
Oxford Oberon had a native DOS build at one time (as did XDS), but all these years years later, I cannot find it. Granted, it had bugs, but it'd be better than nothing. And he still updates it, but only for Windows, Linux, Mac. He already told me he has zero interest in (re)porting to DOS. So I can't even use what already existed. Worse is that compiling it is almost impossible as it relies on (*nix-heavy) OCaml to bootstrap.

OO2C did supposedly build (privately) for DJGPP at one time, but they never released the binaries. Also, in case it wasn't obvious, I've tried several times to build it, but something always goes wrong. It's clearly only meant for *nix as it makes some horrible assumptions. Probably not totally impossible but very hard to get working.

My point isn't useless whining, it's that things did in fact used to work but don't anymore. It's frustrating. Even object formats change, so I have to either hunt down ancient (mostly proprietary) linkers or somehow patch "newer" (similarly abandoned, apparently) free-r ones.

> In every message of yours, the sentiment that everybody somehow unfairly
> treated Dos oozes out. But if there is something at fault, it is the
> remaining Dos users themselves that are at fault. Not the "others".
Software makers refuse to even waste time on DOS. They won't even test in DOSEMU. Sometimes they won't even accept patches. They literally just don't care. Now admittedly most of them don't directly try to piss me off, but sometimes I just gotta wonder, "WHY???" I mean, so much for portability if you assume POSIX, it really kills everything else. I'm surprised Windows has lasted this long with such horrible POSIX-only software out there. I'm also surprised DJGPP ever worked with anything considering all the horrible ideas that come from *nix.

In fact, I even wonder if DJGPP is to blame. It "eased" the translation of POSIX stuff to DOS (and partially Windows) instead of promoting more portable code. But instead of people caring about this end, they went more in the other direction of "more POSIX, more arcane, even less portable", which is frustrating.

I know, it doesn't matter. I need to do everything myself (eh??). I should make my own compilers, OSes, quit whining, start learning. Well, guess what, it's impossible, I'll never be able to replace all that crap. It's just very annoying. I really want to pull all my hair out trying to (re)build something like GCC or anything using AutoTools (./configure) as it often fails for insane reasons. It's just crazy that nobody can write something "simple" that works. The ./configure script is so damn big (I saw one that was 1.6 MB ... freakin' hell!) that you wonder what it's doing. Yeah, just insane.

Okay, rant over. I'm just saying, it's a lot easier to just stick with what you've got. However, you'll be much poorer for it as you won't be able to try various things. It just seems silly to only choose a tool based upon popularity instead of suitability. However, there's only so far you can swim against the tide.
marcov

20.02.2012, 18:54

@ Rugxulo
 

OMF records

Post reply

>
> Modula-3 is pretty cool, but it's main advantages (OOP, generics,
> exceptions, threads, garbage collection) have all been taken over
> (literally) by Java, Python, C#. Others later gained similar features
> (Ada95, C++98, Delphi).
Having features and applying them succesfully is something different. I can remember being significantly underwhelmed by what was presented by specially M3.

Oberon I only got in the earlier mentioned Dos Oberon environment emulation.

> Oberon is nice but probably too minimal for most people as it lacks
> generics, threads, exceptions, and sometimes implementations lack garbage
> collection too.
IIRC one of them also missed unsigned types, making hardware interfacing harder than necessary.

> In other words, there's a lot of competing languages with similar features,
> so there is less reason to try alternatives.
No, I tested M3 and Oberon all in Dos times, so before I knew any of the others. It was in my Modula2 times before Free Pascal.

> It's just a (very) rough guess at what
> people use.

IMHO not even that.

> > But maybe that is the solution? Start adding relevant OMF support to the
> > above watcom linker?
>
> As mentioned, it has support, but obviously there are some hidden quirks
> that need to be ironed out. WLINK is less of a generic OMF linker and more
> of a "this is what our compiler uses" thing.
So fix it :-)

> > I react to your repeated statements about the 32/64-bit open source crowd
>
> > not caring. It is not their task. It is the task of the 16-bit users
> > themselves, and them alone.
>
> Specifically, I meant several things here:
>
> * Their OSes never supported 16-bit (or at least not recently or directly,
> e.g. Win64)
In that specific (win64) case: not even reasonably possible

> * They never used or needed OMF, even the 32-bit extensions
> * They don't care about binary compatibility, esp. with other OSes
> * They nowadays focus more on C/C++ (POSIX) or C#/Java, etc.
I think in the future platforms in general will be less open to not vendor supported development toolchains.

> I didn't mean they have to support 16-bit, just that they don't, for
> various reasons. (Though Windows should have no good excuse, but sigh, lost
> cause.)
I disagree there.

> > > [OMF is] standardized, just nobody cares because they "moved on" to
> newer,
> > > shinier things. Doesn't mean either is better or worse,
> >
> > You should go into politics :-)
>
> Face it, the native preferred format of Win9x/NT was PE/COFF.

Yes.

> Presumably
> some toolsets only used OMF because it was good enough and were able to
> reuse pre-existing tools. That's normal, nobody rewrites everything from
> scratch.
Or they were relatively big in win3.1x. Everybody dealt with 3 OSes (dos,win32s, win32) differently. Some that kept to dos skipped win3.1x (win32s) all together

> > > And for the record, *nix weenies hate a.out and COFF for being old and
> > > badly spec'd, but praise the newer ELF as only thing worth supporting.
> >
> > True. Coff would be dead if it wasn't for Windows supporting derivates.
> But
> > that is a decision taken already in the 1997 timeframe, hardly new.
>
> COFF has a variety of (minor?) problems, hence a few weird extensions to it
> have been done over the years. DJGPP (and EMX and original Linux) all used
> a.out originally. Supposedly DJGPP switched to COFF for various reasons
> (1992?) because it was "best at the time" (pre-existing BinUtils
> support??).

Maybe also OS/2 is a reason (LE instead of PE). OMF was the ugliest child in the class, and there was no good reason to choose it

But it could also be related to what the dosextender supported.

>I can only guess WinNT chose it due to Cutler's VMS (ECOFF??)
> history. Linux switched to ELF for better .so support (among other things,
> e.g. debugging, better C++ handling, etc).
And a better debugging format. Though dwarf is still slow in the coming.

> > Personally, I think because of zero activity.
>
> I don't know, you never know with them (weird political decisions), but
> four of their seven "top tier" platforms for GCC 4.7.0 are Linux
> (presumably ELF) for various architectures. See
> here. And they already
> removed "generic" COFF and such things a while ago.
That's not strange, cygnus being owned by Redhat.

> > The point is that as long as people are willing to work on something it
> is
> > not dead. But that is the problem with Dos. The bulk are users, not
> makers,
> > at least in the programming tools department.
>
> Windows just buys whatever tech they need. *nix just copies Linux (or POSIX
> standard), no brainer, esp. with commercial support from all the weird
> hardware makers out there.
Either way, there is activity, and they manage to hold up their belt.

They don't stand at the sidelines waiting it to be handed to them.

> > > I'd rather not install Oberon OS just to learn Oberon.
> >
> > IIRC there was an Oberon environment that ran on top of Dos? Called
> > "SYSTEM" or something.
>
> Last updated in 1999 or 2001 or such. You really think it'll work on modern
> machines?

Dos is very compatible I'm told :-)

But did you even try? It could be it requires special videocard drivers, maybe it already uses vesa.

> In case you didn't already know, a lot of things break because of
> bad assumptions (esp. re: memory handling). I could be wrong, but I'm
> highly skeptical. However, I don't see how patching that is somehow
> superior to patching this (Oberon-M).
Depends on what you are interested in.

> > Doesn't produce Oberon binaries for use outside that environment, but if
> > learning is the only reason? SPecially since one of the charms of Oberon
> > was the integration with an OOP OS.
>
> The whole point (to me) is to see what I can do portably, and I didn't lose
> my interest in DOS. So I want something that (also) works here. I don't
> want "yet another" Linux/Win/Mac only tool.
Well, you are probably the only one in the world with that preference. So the answer is in what you make of it :)

> > Please :-) Everytime you can't find something it is the old
> > "Linux/BSD/blabla don't care" Calimero argument. And that is usually my
> > trigger :)
>
> They don't care, they openly admit such. It's not just a passive
> disinterest (although that's mostly true), it's downright refusal to help
> with anything outside of their narrow view of the software world.
No. It is that they are the boss of their own time, and you can't willy-nilly commandeer that.

> > No. I'm expecting you to start working on creation of the tools you
> miss,
> > instead of constantly trying to dig into aeons old dirt in the home it
... "in the hope" obviously.

> My point isn't useless whining, it's that things did in fact used to work
> but don't anymore.

yes. And you require effort from others to keep it working for you, and you expect them all to stand up and bow at your call, and are frustrated if they aren't.

It takes time and effort to keep stuff running.

> Software makers refuse to even waste time on DOS. They won't even test in
> DOSEMU. Sometimes they won't even accept patches. They literally just don't
> care.

Of course they don't. Most of them haven't cared for 10 years. It is dead and buried with a ten ton tombstone on top.

The question is why that surprises you still after all this time doing dos.

And how much more you have to hear that before stop asking, and simply either adjust your preferences and requirements (and use what is there rather than go from one hopeless mission to the next trying to be the Guardian Angel of Lost languages on Lost Platforms.), or make a choice, and stick to it for a non trivial amount of time, and simply hit it so hard, and so long till it does what you want.

> Now admittedly most of them don't directly try to piss me off, but
> sometimes I just gotta wonder, "WHY???"

Maintenance costs time.

> I mean, so much for portability if
> you assume POSIX, it really kills everything else. I'm surprised Windows
> has lasted this long with such horrible POSIX-only software out there.
The compatibility is what keeps Windows afloat. Exactly the problem you describe for dos, but then applied to nineties and turn of the century win32 software. Microsoft has made a business model out of it. All the "new" stuff is just to avoid the competition getting so big it hurts the core business. (though admitted, they failed horribly at that wrt Apple)

> I'm also surprised DJGPP ever worked with anything considering all the horrible ideas that come from *nix.
Open source unix. Commercial unix is way better backwards compatible.

> In fact, I even wonder if DJGPP is to blame. It "eased" the translation of
> POSIX stuff to DOS (and partially Windows) instead of promoting more
> portable code. But instead of people caring about this end, they went more
> in the other direction of "more POSIX, more arcane, even less portable",
> which is frustrating.
I don't see POSIX as such a magic word (or even as somethign concrete). So I don't agree here.

> I know, it doesn't matter. I need to do everything myself (eh??). I should
> make my own compilers, OSes, quit whining, start learning.

If you care enough to do two years of similar tirades here, then yes, make a list, take the one closest to the top, compromise to make it doable, and start working.

Flaming here isn't going to solve anything, except feeding your own frustrations.

> Okay, rant over. I'm just saying, it's a lot easier to just stick with what
> you've got.

well, spoken as a real DOSSer :-)
Rugxulo

Homepage

Usono,
20.02.2012, 20:09

@ marcov
 

OMF records

Post reply

(part one):

> > Define "simple". FALSE? PL/0? Oberon/0?
>
> For any somewhat normal procedural or OOP language. You can try to find
> extreme cases of course, but that doesn't really say anything.
Wirth's goal has been to keep the EBNF short, able to bootstrap itself in a minute (even on very slow hardware of the day). Granted, he seems to prefer one-pass, only minimal optimizations when needed, and semi-direct binary output.

Modula-3 intentionally kept their report in 50 or so pages (vs. much more complex ISO Modula-2, Ada, C++). They meant to keep it orthogonal and heavily used it on-site at DEC.

However, neither were really interested in 16-bit at all, and Modula-3 admittedly seemed too heavily POSIX-oriented (plus Win32, natch).

> > Heck, Wirth's ARM compiler for 32-bit OberonSA (-07 variant?) is
> > only 61 kb.
>
> Minimal language, minimal compiler. God knows how much effort. Irrelevant.
Not irrelevant, but admittedly he's experienced, educated, hard-working. So I can't compete with that. :-P

> > So FreeDOS trumps them all.
>
> Well, I couldn't get 1.1 to install, so leave the trumps away ;-)
> It couldn't find the cdrom it booted from :-)
<sarcasm>
That's your problem, not ours. If you can't be bothered to read a manual or learn how to install it properly from experience, you'll get left behind. We can't cater to those who refuse to adhere to 30 years of experience.
</sarcasm>

> > But stuff still gets done. Granted, some people
> > prefer newer things.
>
> If it was, freedos would have superseded them all by now, based on an own
> dos-only toolchain.

I just don't get it. People adore the "classic" (piece of crap) NES that had barely any RAM or capabilities, but a semi-modern DOS machine is considered useless. What gives?

> > (BTW, speaking of that, shouldn't you be busy porting
> > Lazarus to WinRT/Metro?
>
> No. You still don't get the base premise of this subthread. One is supposed
> to develop for what you use. I don't have winrt
Well, you seem to be more biased towards "modern" than I am. It's just so many things appear as "latest greatest" or (worse) "a better xyz than abc" to replace "legacy" things. Too many moving targets, no stability.

> > It's hardly inertia. Software isn't easy to rewrite.
>
> Why does nearly every niche community then have more to show for it than
> Dos?
Politics. Laziness. Ignorance. Lack of time. Preference for fancier things. Inability to minimize dependencies. Real life. Lack of money. Less support that previously existed.

> > Yes, I should just use FPC on everything 100% of the time.
>
> Of course! Have I ever said anything else? :-D

FPC does have serious advantages over others, but most of that is from hard work and not relying too much upon GNU / POSIX stuff (thankfully).

> I never cared much for either M3 or Oberon. At least for normal usage,
> they might have been great experiments in the past.
They are quite good, but I can see where FPC (mostly) negates the need for them.

(part two):

> I can remember being significantly underwhelmed by what was presented
> by specially M3.
>
> Oberon I only got in the earlier mentioned Dos Oberon environment
> emulation.
Some of the advantages are behind the scenes and not as obvious as other, flashier features. I.e. Oberon seems to have one-to-one translation for a lot of things (e.g. BIFs, low overhead). Modula-3 was considered extremely typesafe and well thought out. Both had freely available, portable implementations.

> IIRC one of them also missed unsigned types, making hardware interfacing
> harder than necessary.
Even Ada83 and Java lack unsigned, IIRC. (The guy who ported DOSBox to Java whined about that too, heh.) The only reason Modula-2 had CARDINAL was because of 16-bit memory limits (and also because the hardware supported it separately), but it complicated the type compatibility, so Wirth simplified for Oberon. Modula-3 also simplified by having FIRST(CARDINAL)..LAST(CARDINAL) = 2 GB (aka, positive subset of INTEGER and subset of typical native wordsize 4 GB unsigned integer, which was only accessible via the Word.T interface).

So in short, it probably isn't needed much and can be worked around in low-level ways if direly needed.

> > Specifically, I meant several things here:
> >
> > * Their OSes never supported 16-bit (or at least not recently or
> directly,
> > e.g. Win64)
>
> In that specific (win64) case: not even reasonably possible
Sure it's possible. If Alpha can emulate x86, then Win64 can too. If DOSEMU x64 can do it, so can Win7. Heck, Microsoft had a 486 emulator for non-x86 WinNT machines already. But anyways, it's moot, they consider 16-bit not worth the effort, and that's the "real" reason.

> That's not strange, cygnus being owned by Redhat.
It's not strange at all, but let's face facts, GNU (FSF) cares heavily about Linux and ELF but very little about other stuff. GCC isn't the uber-portable do-everything compiler anymore. It's becoming more only about FSF than just a simple compiler (for good or bad).

BTW, DJ Delorie works for Red Hat.

> > > > I'd rather not install Oberon OS just to learn Oberon.
> > >
> > > IIRC there was an Oberon environment that ran on top of Dos? Called
> > > "SYSTEM" or something.
V4? System 3? Yes, there was a (barely) DOS-hosted version, but it was (AFAIK) superceded by "Native" Oberon.

> > Last updated in 1999 or 2001 or such. You really think it'll work on
> modern
> > machines?
>
> Dos is very compatible I'm told :-)
I'm not talking about DOS, I'm talking about bad assumptions in old software that assumes you don't have 6 GB. :-) A lot of stuff chokes because it never thought we'd see the day.

Windows stuff breaks too, esp. 'cause of old installers or stuff you can't rebuild. But there you're just out of luck without similar workarounds. Linux doesn't care if old stuff works, and even if you're allowed to rebuild, it doesn't always work (stupid GCC or similar bugs).

> But did you even try? It could be it requires special videocard drivers,
> maybe it already uses vesa.
No, I didn't try because I didn't "need" it that badly. Plus I'm very skeptical. But sure, maybe?? it works? ;-) Honestly, I'd be better off running it under VirtualBox. Heck, I'm even too skeptical to try the Win95 plugin version because Win64 is so annoying, meh.

> Well, you are probably the only one in the world with that [DOS]
> preference. So the answer is in what you make of it :)
I know, and it's a self-imposed difficulty. My problem is that I expect old stuff to keep working and continue to be available, but it doesn't and won't. I disagree with that.

> No. It is that they are the boss of their own time, and you can't
> willy-nilly commandeer that.
Don't want to commandeer them, but if it used to work, it should still work. Or at least old version should be available. But it's not.

> yes. And you require effort from others to keep it working for you, and you
> expect them all to stand up and bow at your call, and are frustrated if
> they aren't.
They can't even host online an old .ZIP file. Is that too much to ask? Apparently so.

> Of course they don't. Most of them haven't cared for 10 years. [DOS]
> is dead and buried with a ten ton tombstone on top.
So is C (according to C++) or both according to Java and C#. MS wants WinXP dead too. Mac OS X can't even support things for more than two years, barely. It's just weird, everything modern is such a moving target.

> The question is why that surprises you still after all this time doing
> dos.
I don't know. I just always read about, "Our project xyz is so great and portable", but it's not portable, it's just for "modern" big three OSes only. I always falsely get my hopes up.

> either adjust your preferences and requirements (and use what is there
> ... or make a choice, and stick to it for a non trivial amount of time,
> and simply hit it so hard, and so long till it does what you want.
Easier said than done.

> Maintenance costs time.
They have plenty of time to port to Android or iOS or other dumb things that are so gimmicky and new and unstable that it's not worth using (IMO). They also waste time on other similarly unfinished things like HTML5 or constantly upgrading their software (Firefox 10? downloading ...) ad nauseum, i.e. making yet another distro release or packages in xyz format that nobody but a few support.

> The compatibility is what keeps Windows afloat. Exactly the problem you
> describe for dos, but then applied to nineties and turn of the century
> win32 software. Microsoft has made a business model out of it.
Not anymore, not in a long time. XP was the last of that. Now everything is all about new software, new drivers, etc.

> All the
> "new" stuff is just to avoid the competition getting so big it hurts the
> core business. (though admitted, they failed horribly at that wrt Apple)
Nah, MS always wants to copy or compete in everything technology-based. Sometimes I wonder why they bother in some fields. They're weirdly unpredictable.

> Flaming here isn't going to solve anything, except feeding your own
> frustrations.
It's not just whining, I have often tried rebuilding some "modern" things with DJGPP, but it almost never works. Sad, really. I wonder how I ever have the nerve considering all the failures.

> it's a lot easier to just stick with what you've got.
>
> well, spoken as a real DOSSer :-)
In other words, the easy way out is "just use C", which is freakin' everywhere, or maybe something well-supported like Ada or FPC. I just can't resist looking into niche things sometimes. So it's old and barely used, so what? It might be cool! ;-)
Japheth

Homepage

Germany (South),
16.02.2012, 18:08

@ Rugxulo
 

OMF records

Post reply

If you can provide a FULL test case ( object modules! ), I'll feed them to my fork of wlink. If errors occur at the link step, it won't be too hard to tell why wlink doesn't like the modules.

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
16.02.2012, 19:48

@ Japheth
 

OMF records

Post reply

> If you can provide a FULL test case ( object modules! ), I'll feed them to
> my fork of wlink. If errors occur at the link step, it won't be too hard to
> tell why wlink doesn't like the modules.
I probably tried that one too, but I don't think it worked either. I will try again, but I am not getting my hopes up. (Hmmm, very slightly newer .ZIPs than I already had, glad I re-checked.)

BTW, how many (sub)versions of OMF exist: Intel, MS, Borland, TIS, ... ? Like I said, this compiler is circa 1991, so it's probably assuming MS compatible, pre-standard (though you'd think they'd try to still accept that too, sheesh).

(BTW, Arjay, ALINK 1.7 beta precompiled is (also) available in AW.ZIP from EJI. Yup, dated from 2000 too, ugh, aka abandoned. I know the ALINK author is nowadays big on C++ and multithreading as I saw him post on one of the OpenWatcom newsgroups a year or so ago, but I didn't bother bringing up old stuff.)
Arjay

16.02.2012, 21:27

@ Rugxulo
 

OMF records

Post reply

> (BTW, Arjay, ALINK 1.7 beta precompiled is (also) available in
> AW.ZIP from EJI.

I am pretty sure that I discovered that there was a later version of alink than the one on Eric's site (1.9 seems to ring a bell). I am a registered A86 user, however I seem to remember getting it from a difference source to Eric.
Unfortunately I'm not in a position where I can easily check my A86 related dev stuff at the minute but I do seem to remember upgrading to newer alink.
Arjay

16.02.2012, 21:52

@ Arjay
 

OMF records

Post reply

> > (BTW, Arjay, ALINK 1.7 beta precompiled is (also) available in
> > AW.ZIP from EJI.
>
> I am pretty sure that I discovered that there was a later version of alink
> than the one on Eric's site (1.9 seems to ring a bell). I am a registered
> A86 user, however I seem to remember getting it from a difference source to
> Eric.
> Unfortunately I'm not in a position where I can easily check my A86 related
> dev stuff at the minute but I do seem to remember upgrading to newer alink.
Just occurred to me to check my email archive and I found a 2008 email to Eric: I seem to remember locating a newer version (v1.7) than I think the one I found in your own site:

04/09/2000 10:32 485,888 ALINK.EXE
ALINK v1.7 alpha (C) Copyright 1998-2000 Anthony A.J. Williams.
All Rights Reserved

So it seems that I must have been using 1.6 from Eric before upgrading to 1.7 (which he nows has). As per the BTTR links you will find the last distro @
http://alink.sourceforge.net/

The same email to Ericalso reminded me of Jeremy Gordon's GoLink etc:
http://www.godevtool.com/#linker
not helpful in this instance but a useful set of tools to also be aware of.
Rugxulo

Homepage

Usono,
16.02.2012, 23:09

@ Arjay
 

OMF records

Post reply

> > > (BTW, Arjay, ALINK 1.7 beta precompiled is (also) available in
> > > AW.ZIP from EJI.
> >
> > I am pretty sure that I discovered that there was a later version of
> alink
> > than the one on Eric's site.
>
> Just occurred to me to check my email archive and I found a 2008 email to
> Eric: I seem to remember locating a newer version (v1.7) than I think
> the one I found in your own site:
>
> 04/09/2000 10:32 485,888 ALINK.EXE
> ALINK v1.7 alpha (C) Copyright 1998-2000 Anthony A.J. Williams.
>
>
> So it seems that I must have been using 1.6 from Eric before upgrading to
> 1.7 (which he nows has). As per the BTTR links you will find the last
> distro @
> http://alink.sourceforge.net/
IIRC, the prebuilt binaries are 1.6 only, so you have to get 1.7 beta from CVS (or whatever). I haven't heavily used ALINK, esp. not recently, so I don't know the ins and outs. Originally I think it was just meant to be a portable linker for use with NASM. But obviously, like I said, it seems to not have been developed since 2000 (11 years ago).

Anyways, here is the thread on news://openwatcom.contributors from two years ago (03 March 2010) where Mr. ALINK himself popped up (re: C++ and multithreading).
Rugxulo

Homepage

Usono,
17.02.2012, 02:15

@ Japheth
 

OMF records

Post reply

> If you can provide a FULL test case ( object modules! ), I'll feed them to
> my fork of wlink. If errors occur at the link step, it won't be too hard to
> tell why wlink doesn't like the modules.
I played with it a bit more, but I'm really unfamiliar with WLINK syntax. I ended up doing something like "format dos name blah file abc,xyz,out,term,sys", which would give a few warnings, create an .EXE, but that wouldn't run, wrongly claimed xyz module is older than whatever. (That error detection part is apparently embedded in SYS.OBJ, whose source is not included. I don't think you really need it, but I don't know why it's confused here.) Anyways, for comparison, this does not happen with TLINK or MS LINK or VALX. I'm not sure why, there's too many oddball things going on that are beyond my knowledge as I'm not super familiar with OMF innards. It might be order-specific, as in main module has to be linked first, SYS.OBJ has to be linked last. Is that enforceable with WLINK? (Semi-educated guess but could be wrong.)

Anyways, you don't need any examples from me, OBERNM12.ZIP already has two example projects: ABU, and OE (plus their pre-generated .OBJ files). If you do decide to recompile something, remember that "oc blah.mod def" (generate the .REF) must come first before "oc blah.mod" (generate the .OBJ) except for the main module.

P.S. Tried WarpLink again (though I knew it didn't work), aborts linking (with no resulting .EXE) due to no stack size or stack too large or whatever. I didn't honestly know where to patch that, so I couldn't fiddle with it (yet). See what I mean about most linkers hating its output?
Japheth

Homepage

Germany (South),
17.02.2012, 08:08

@ Rugxulo
 

OMF records

Post reply

> I played with it a bit more, but I'm really unfamiliar with WLINK syntax. I
> ended up doing something like "format dos name blah file
> abc,xyz,out,term,sys", which would give a few warnings, create an .EXE, but
> that wouldn't run, wrongly claimed xyz module is older than whatever. (That
> error detection part is apparently embedded in SYS.OBJ, whose source is not
> included. I don't think you really need it, but I don't know why it's
> confused here.) Anyways, for comparison, this does not happen with TLINK or
> MS LINK or VALX. I'm not sure why, there's too many oddball things going on
This is not really a high-quality error report. You should post the exact warning and error messages and also post the exact command line you used for both MS link and WLINK. I'm familiar with both linkers. Additionally, you should make the linkers create MAP files - by comparing the two resulting map files it will most likely become obvious what's wrong with wlink.

For wlink, to create a map file enter:

"format dos name blah file abc,xyz,out,term,sys op map"

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
17.02.2012, 20:21

@ Japheth
 

OMF records

Post reply

> This is not really a high-quality error report.
Please download JAPHETH.ZIP.

I automated literally everything, so it should be extremely obvious what to do.

> You should post the exact
> warning and error messages and also post the exact command line you used
> for both MS link and WLINK. I'm familiar with both linkers.
I am not using MS LINK here (though I did briefly test it a few months back, and it works). That was the linker at which Oberon/M was originally targeted.

I did include JAPHETH.ERR in the above archive with the (failed) results of JWLINKD. Perhaps I'll also quote it here for full reveleation:


[ FreeDOS ] G:\TONY>jwlinkd format dos file newbef93,stacks,in,out,term,sys
JWlink Version 1.9
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
loading object files
Warning! W1032: file newbef93.obj(NEWBEF93), record 25: record (type 0x0070) not
 processed
Warning! W1014: stack segment not found
Warning! W1023: no starting address found, using 0000:0000
creating a DOS executable
[ FreeDOS ] G:\TONY>newbef93 < alphabox.bef
Run time error code:       4
compiled with old version of module
In
in module In
[ FreeDOS ] G:\TONY>scrndump c:\tmp\japheth.err


At least, to me, this makes absolutely no sense. I don't know how or if the runtime is somehow checking the .REF files for consistency (internal module key), but that's what it appears to be doing. That should only be checked at compile-time, but I have no idea what this particular one is doing. TLINK doesn't whine. I'm fairly sure there is no failure in compiled module and (symbol) definition consistency, so the problem lies elsewhere.

> Additionally,
> you should make the linkers create MAP files - by comparing the two
> resulting map files it will most likely become obvious what's wrong with
> wlink.
It is not obvious. Please define "obvious". No, seriously, there's even a blank-named empty segment in there for whatever reason. And I still wonder if link order matters. You never did tell me if it's possible to specify that, so I dunno (tried and failed). There is a warning about "no stack segment", which I assumed was spurious, but perhaps there is some significance, I don't know. One of my source files is named STACKS, which I blindly assumed was confusing the linker, but renaming it (STORK, had to pick something unique, heh) didn't help anything (so don't waste time on that).

> For wlink, to create a map file enter:
>
> "format dos name blah file abc,xyz,out,term,sys op map"
Didn't help, at least not for me. I don't understand all the intricacies of EXE or OMF relocations, and I have no idea where or why Oberon/M is putting code, data, stack etc. It may be a latent compiler bug. Well, it's just old and not heavily tested in modern linkers, so what did we expect? That's the "real" problem.
Japheth

Homepage

Germany (South),
18.02.2012, 09:05

@ Rugxulo
 

OMF records

Post reply

>
> Please download
> JAPHETH.ZIP.
>
> I automated literally everything, so it should be extremely obvious what to
> do.
Ok, I downloaded it. Additionally, I needed obernm12.zip file and tlink+make from Borland.

After adjusting some paths in RUNME.BAT, the think "runs", but outputs a warning:

warning: no stack defined

and if I start the resulting executable newbef93.exe, it just freezes. This happens with tlink version 2.0 (I don't have v1.01; if I use a newer tlink (v7.1.30) instead, the linker displays "error: Invalid initial stack offset" and no exe is generated). Is this the expected behavior?

>
> [ FreeDOS ] G:\TONY>jwlinkd format dos file
> newbef93,stacks,in,out,term,sys
> JWlink Version 1.9
> Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
> Source code is available under the Sybase Open Watcom Public License.
> loading object files
> Warning! W1032: file newbef93.obj(NEWBEF93), record 25: record (type
> 0x0070) not
> processed
> Warning! W1014: stack segment not found
> Warning! W1023: no starting address found, using 0000:0000
> creating a DOS executable
> [ FreeDOS ] G:\TONY>newbef93 < alphabox.bef
> Run time error code:       4
> compiled with old version of module
> In
> in module In
> [ FreeDOS ] G:\TONY>scrndump c:\tmp\japheth.err
>
>
> At least, to me, this makes absolutely no sense.
Warnings 1014 and 1023 are usually severe, but in this case they probably can be ignored because tlink also warns about the missing stack and tells in the map file that entry point is 0000:0000. Warning W1032 is most likely minor, because the record is just ignored and AFAIU the record isn't needed anyway.

> It is not obvious. Please define "obvious".
With "obvious" I meant "obvious to me AFTER you posted both map files here".

> No, seriously, there's even a
> blank-named empty segment in there for whatever reason. And I still wonder
> if link order matters.
It usually matters. There are linker options (DOSSEG) which tell the linker that segments are to be ordered in a special way, but I guess this doesn't apply here.

I created both map files.

tlink:


 00000H 008C7H 008C8H NEWBEF93           
 008C8H 008C8H 00000H                   
 008D0H 02189H 018BAH DATA               
 02190H 024EAH 0035BH SYS               
 024F0H 0261BH 0012CH IN                 
 02620H 028B2H 00293H TERM               
 028C0H 02977H 000B8H OUT               
 02980H 02AA1H 00122H STACKS             
 02AB0H 12AB0H 10000H STACK             


jwlink:


NEWBEF93            AUTO           0000:0000       000008c8
DATA                AUTO           0000:08d0       000018ba
SYS                 AUTO           0000:2190       0000035b
                    AUTO           024e:000b       00000000
IN                  AUTO           024f:0000       0000012c
TERM                AUTO           024f:0130       00000293
OUT                 AUTO           024f:03d0       000000b8
STACKS              AUTO           024f:0490       00000122
STACK               AUTO           02ab:0000       00010000


The only difference is the location of the unnamed and "empty" segment. However, even an "empty" segment matters: it may define a "label" which is used somewhere inside the binary or it may be used to force a certain alignment (alignment to paragraphs in this case).

However, to make further investigations I first have to know what your program is supposed to do and display.

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
18.02.2012, 16:39

@ Japheth
 

OMF records

Post reply

> Ok, I downloaded it. Additionally, I needed obernm12.zip file and
> tlink+make from Borland.

Yes. I don't have redistribution permission for TCPP101.ZIP, and OBERNM12.ZIP was pointed to in a previous post.

> After adjusting some paths in RUNME.BAT, the think "runs", but outputs a
> warning:
>
> warning: no stack defined
As expected.

> and if I start the resulting executable newbef93.exe, it just freezes. This
> happens with tlink version 2.0 (I don't have v1.01; if I use a newer tlink
> (v7.1.30) instead, the linker displays "error: Invalid initial stack
> offset" and no exe is generated). Is this the expected behavior?
No, that's not expected. I thought you would've had 1.01. I also thought it wouldn't majorly bork in newer versions (sigh).

It's supposed to run three files successfully: one showing 25**5, one showing a simple ASCII box, and one showing a big ASCII drawing. So no, it's not supposed to hang or be silent. It's supposed to be obvious that it works (with TLINK from 1.01).

> >
> > JWlink Version 1.9
> > Warning! W1032: file newbef93.obj(NEWBEF93), record 25: record (type
> > 0x0070) not
> >  processed
> > Warning! W1014: stack segment not found
> > Warning! W1023: no starting address found, using 0000:0000
> >
> >
> > At least, to me, this makes absolutely no sense.
>
> Warnings 1014 and 1023 are usually severe, but in this case they probably
> can be ignored because tlink also warns about the missing stack and tells
> in the map file that entry point is 0000:0000.
I have no idea why, but that can't be a good sign. I just figured it was old. I also blindly figure the author knew what he was doing. Perhaps not (heh). It may just be some other old or obsolete thing that changed in linkers or OMF variants later on.

> Warning W1032 is most likely
> minor, because the record is just ignored and AFAIU the record isn't needed
> anyway.
Like I said, I'm almost positive that MS LINK ignores it. But TIS 1.1 says it's obsolete and should return an error (dang it), which most linkers indeed do. Which is bad, esp. because it's not needed, and you need a working linker to build the .EXE! Hence my silly hack to (effectively) nop out the damn record.

P.S. Try VALX from CC386 (after running HACKOMF on NEWBEF93.OBJ), it works.

> > It is not obvious. Please define "obvious".
>
> With "obvious" I meant "obvious to me AFTER you posted both map files
> here".
I figured you had all the tools to regenerate everything. (Though admittedly Embarcadero is more stingy these days with the "freeware" Borland tools.)

> > No, seriously, there's even a
> > blank-named empty segment in there for whatever reason. And I still
> wonder
> > if link order matters.
>
> It usually matters. There are linker options (DOSSEG) which tell the linker
> that segments are to be ordered in a special way, but I guess this doesn't
> apply here.
I had tried DOSSEG with JWLINK, didn't help.

> I created both map files.
>
> The only difference is the location of the unnamed and "empty" segment.
> However, even an "empty" segment matters: it may define a "label" which is
> used somewhere inside the binary or it may be used to force a certain
> alignment (alignment to paragraphs in this case).
>
> However, to make further investigations I first have to know what your
> program is supposed to do and display.
It's a Befunge-93 interpreter. It's not supposed to hang or be silent, it's supposed to read from stdin and write to stdout (normally from input file but none of the Oberon compilers I tested had any pseudo-standard libs). If running "newbef93 < guesswho.bef" succeeds, you will know it because it will write a big ASCII pic to your screen.
Japheth

Homepage

Germany (South),
18.02.2012, 17:55

@ Rugxulo
 

OMF records

Post reply

> No, that's not expected. I thought you would've had 1.01. I also thought it
> wouldn't majorly bork in newer versions (sigh).
Ok, it "works". The information that one has to provide a cmdline argument for newbef93.exe helped. It works with valx (needs a patched newbef93.obj) and also with MS link v5.1 from 1990 (doesn't need patching).

jwlink and wlink won't work. There are 2 errors

1. they both ignore the STACK combine type of a segment and instead rely on the stack segment to have class "STACK". This is a known issue, it was discussed a few years ago in the OW contributors newsgroup. I just fixed this issue for jwlink.

2. wrong DOS segment fixups are created. I guess this is because all segments have the same class name (in fact it is "", that is, no segment has a class name, but (j)wlink has no special handling for empty class names). Probably not too hard to fix for jwlink. It's a quite common experience with the OW tools: they work quite well as long as you stay in the OW world, but tend to fail immediately if something is done slightly "unusual".

---
MS-DOS forever!
Japheth

Homepage

Germany (South),
20.02.2012, 14:31

@ Japheth
 

jwlinkd updated

Post reply

I made a small update to http://www.japheth.de/Download/JWlink/JWlinkbd.zip , which has the following changes:

> 1. they both ignore the STACK combine type of a segment and instead rely on
> the stack segment to have class "STACK".
fixed

> 2. wrong DOS segment fixups are created. I guess this is because all
> segments have the same class name (in fact it is "", that is, no segment
> has a class name, but (j)wlink has no special handling for empty class
> names.
fixed. Segments with unknown "type" were put in a so-called AUTO group (I don't know why). This didn't work for Oberon.

After these fixes your sample did run, linked with jwlink.

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
20.02.2012, 20:14

@ Japheth
 

Oberon subtyping (was: JWlinkD updated)

Post reply

> I made a small update to http://www.japheth.de/Download/JWlink/JWlinkbd.zip
> , which has the following changes:
 >...
> After these fixes your sample did run, linked with jwlink.
Cool, thanks. Yes, it seems to work.

BTW, here's another silly example just to demonstrate the subtyping of Oberon:


MODULE blah;
IMPORT O := Out;

TYPE object = RECORD END;
     Tchar   = RECORD (object) c: CHAR END;
     Tstring = RECORD (object) str: ARRAY 255 OF CHAR END;
     Tinteger= RECORD (object) i: LONGINT END;

VAR name: Tstring; number: Tinteger; grade: Tchar;

PROCEDURE write(VAR o: object);
BEGIN
  IF o IS Tchar THEN O.Char(27X); O.Char(o(Tchar).c); O.Char(27X)
  ELSIF o IS Tstring THEN O.Char(22X); O.String(o(Tstring).str); O.Char(22X);
  ELSIF o IS Tinteger THEN O.Int(o(Tinteger).i,1)
  ELSE O.Ln; O.String("dunno")
  END;
  O.Ln
END write;

BEGIN (* blah *)
  grade.c := "B"; number.i := 5150H; COPY("dosuser",name.str);

  write(name); write(number); write(grade);
END blah.
Rugxulo

Homepage

Usono,
06.03.2012, 23:30

@ Rugxulo
 

BEFI 3H (Oberon-M fully supported)

Post reply

Sorry to bump this thread, but I did update (again) my silly Befunge interpreter collection (BEFI_3H.ZIP). Now, Oberon-M output fully works with cmdline loading from file, random via '?', keyboard input, no longer limited to a portable subset. The build is automated via .BAT, and due to lack of standard libraries, I just mimicked Oxford's interfaces. (Though curiously I haven't benchmarked it much, but the 8086 output seems 5x faster than 186 output [ENTER, LEAVE?] on this Core i5. Goofy stuff.)

Also, I found via WayBack the old Oxford 1.4 (DJGPP-based) compiler, but their archive didn't also have sources, sadly. Nevertheless, it "mostly" works with a few tweaks (i.e. why he put it inside a Win32 .CAB PE/EXE installer is beyond me; luckily, p7zip to the rescue!). Though if you copy over files from already-installed 2.9.2 and the (correct 32-bit) MSVCRT.DLL from your Windows installation (since MSVCRT.DLL is not freely redistributable), you can use the current Win32 build under HX. (XDS probably still works too, but I haven't tried lately.)

BTW, while Oberon-M isn't open source, it's based upon the compiler presented in Wirth's Project Oberon book. Also of interest are Programming in Oberon and Mossenbock's OOP in Oberon-2.

P.S. Yes, I did try booting DOS-based Oberon atop native FreeDOS (FAT32) as well as VirtualBox (FAT16, FAT32) with or without VT-X, but it always failed. I have not tried any of the other versions (Native, AOS, plugin), which presumably aren't as buggy.
Arjay

18.02.2012, 14:22
(edited by Arjay, 18.02.2012, 14:59)

@ Rugxulo
 

OMF records - processing SYS.OBJ with tdstrip

Post reply

> > This is not really a high-quality error report.
>
> Please download
> JAPHETH.ZIP.
I also downloaded the above. First thoughts were that the oberon examples you provided were too complex for a good test, e.g. a hello world would have been better. I also thought about a different approach. Fields in oberon's SYS.OBJ appears to be a problem, so I thought about passing it through TSTRIP:

SYS      OBJ              1,178 18-02-2012 13:02
SYSTEST  OBJ              1,113 18-02-2012 13:06


Before:

Turbo Dump  Version 4.2.16.1 Copyright (c) 1988, 1996 Borland International

                      Display of File SYS.OBJ



000000 THEADR  SYS.ASM

00000C COMENT  Purge: Yes, List: Yes, Class: 0   (000h)

    Translator: urbo Assembler  Version 1.0º

00002E COMENT  Purge: Yes, List: No , Class: 233 (0E9h)

    Dependency File: SYS.ASM               12/27/89  10:04:07 am

000040 COMENT  Purge: Yes, List: No , Class: 233 (0E9h)

    End of Dependency List

000046 LNAMES

    Name  1: ''

00004B LNAMES

    Name  2: 'SYS'

000053 SEGDEF 1 : SYS             PARA  PUBLIC                   Length: 035b

00005D PUBDEF  'SYSINIT'               Segment: SYS:0228

00006E PUBDEF  'SYSSTOR'               Segment: SYS:0268

00007F PUBDEF  'SYSSTGRL'              Segment: SYS:033C

000091 PUBDEF  'SYSLIDIV'              Segment: SYS:02CD

0000A3 PUBDEF  'SYSCALL'               Segment: SYS:0239

0000B4 PUBDEF  'SYSABEND'              Segment: SYS:0199

0000C6 PUBDEF  'SYSLIMUL'              Segment: SYS:02B2

0000D8 COMENT  Purge: Yes, List: No , Class: 162 (0A2h)

    Linker - Pass Two Marker.

0000DF LEDATA  Segment: SYS            Offset: 0004  Length: 0357




after tdstrip:

Turbo Dump  Version 4.2.16.1 Copyright (c) 1988, 1996 Borland International

                    Display of File SYSTEST.OBJ



000000 THEADR  SYS.ASM

00000C LNAMES

    Name  1: ''

000011 LNAMES

    Name  2: 'SYS'

000019 SEGDEF 1 : SYS             PARA  PUBLIC                   Length: 035b

000023 PUBDEF  'SYSINIT'               Segment: SYS:0228

000034 PUBDEF  'SYSSTOR'               Segment: SYS:0268

000045 PUBDEF  'SYSSTGRL'              Segment: SYS:033C

000057 PUBDEF  'SYSLIDIV'              Segment: SYS:02CD

000069 PUBDEF  'SYSCALL'               Segment: SYS:0239

00007A PUBDEF  'SYSABEND'              Segment: SYS:0199

00008C PUBDEF  'SYSLIMUL'              Segment: SYS:02B2

00009E LEDATA  Segment: SYS            Offset: 0004  Length: 0357



Unfortunately I have other things to do but I thought I would share the above, so you could see if tidying up SYS.OBJ with tstrip helps resolve.
Arjay

18.02.2012, 15:47
(edited by Arjay, 18.02.2012, 16:03)

@ Arjay
 

OMF records - processing SYS.OBJ with tdstrip

Post reply

> too complex for a good test, e.g. a hello world would have been better.
params.mod (mod is the file extension used for src) which comes with the compiler is a good basic example. However to aid with testing I created an even shorter one:

MODULE rjtest;   (* RJTEST 2012 *)

  IMPORT SYS:=SYSTEM;

BEGIN
END rjtest.

Using a tstrip processed SYS.OBJ. I copied OC.EXE and SYS.OBJ into a test directory and tried to compile rjtest.mod (as above) with oc, tlink etc:

map file:
Error: Invalid initial stack offset
 Start  Stop   Length Name               Class
 00000H 00021H 00022H RJTEST
 00022H 00022H 00000H
 00030H 00039H 0000AH DATA
 00040H 00040H 00000H SYS
 00040H 1003FH 10000H STACK


tdump of RJTEST.OBJ:
Turbo Dump  Version 4.2.16.1 Copyright (c) 1988, 1996 Borland International
                    Display of File RJTEST.OBJ

000000 THEADR  RJTEST
00000B COMENT  Purge: No , List: Yes, Class: 0   (000h)
    Translator:   Oberon-M (tm) PC  v0.1    Ï

00002E LNAMES
    Name  1: 'RJTEST'
    Name  2: 'DATA'
    Name  3: 'STACK'
    Name  4: 'SYS'
    Name  5: ''
000049 SEGDEF 1 : RJTEST          PARA  PUBLIC                   Length: 0022
000053 SEGDEF 2 : DATA            PARA  PUBLIC                   Length: 000a
00005D SEGDEF 3 : SYS             PARA  PUBLIC                   Length: 0000
000067 SEGDEF 4 :                 BYTE  PUBLIC                   Length: 0000
000071 SEGDEF 5 : STACK           PARA  STACK                    Length: 10000
00007B EXTDEF 1 : 'SYSCALL'             Type: 0 
        2 : 'SYSINIT'             Type: 0 
        3 : 'SYSSTOR'             Type: 0 
        4 : 'SYSABEND'            Type: 0 
        5 : 'SYSLIDIV'            Type: 0 
        6 : 'SYSLIMUL'            Type: 0 
        7 : 'SYSSTGRL'            Type: 0 
0000C2 LEDATA  Segment: DATA           Offset: 0000  Length: 0002
    0000: 00 00                                              ..
0000CB LEDATA  Segment: RJTEST         Offset: 0000  Length: 001B
    0000: E9 02 00 1B 00 FC B8 00  00 8E D8 9A 00 00 00 00   ................
    0010: 55 8B EC 8B E5 5D B8 00  4C CD 21                  U....]..L.!
0000ED FIXUPP
    FixUp: 007  Mode: Seg  Loc: Base        Frame: SI[2]   Target: SI[2]
    FixUp: 00c  Mode: Seg  Loc: Pointer16   Frame: TARGET  Target: EI[2]
0000FA LEDATA  Segment: RJTEST         Offset: 001B  Length: 0007
    0000: 72 6A 74 65 73 74 00                               rjtest.
000108 REGINT  Record type: 70  Length: 000C
    0000: 01 04 01 01 41 04 05 05  81 04 02 02               ....A.......
000118 MODEND(Main Module) Starting address: 01F4:0504

So processing SYS.OBJ with tdstrip didn't help much as the issue of an invalid entry point still exists and the blank byte record still gets inserted as well as the REGINT (70h) record.

As when I get a chance I will do some more testing/investigation. Re the REGINT (70h) record I'm thinking that patching OC.EXE is needed to resolve.

[edit: if IMPORT SYS:=SYSTEM; is missing it seems OC defaults to it]
Rugxulo

Homepage

Usono,
18.02.2012, 17:12
(edited by Rugxulo, 18.02.2012, 17:28)

@ Arjay
 

OMF records - processing SYS.OBJ with tdstrip

Post reply

> > too complex for a good test, e.g. a hello world would have been better.
> params.mod (mod is the file extension used for src) which comes with the
> compiler is a good basic example. However to aid with testing I created an
> even shorter one:
>
> MODULE rjtest;   (* RJTEST 2012 *)
>
> IMPORT SYS:=SYSTEM;
>
> BEGIN
> END rjtest.

I think that's too simple for testing (see above). It doesn't have multiple modules and doesn't actually do anything. ("SYS" is, apparently, an obsolete naming convention for "SYSTEM", which itself is only used for non-portable code, low-level stuff, etc.)

> Using a tstrip processed SYS.OBJ. I copied OC.EXE and SYS.OBJ into a test
> directory and tried to compile rjtest.mod (as above) with oc, tlink etc:
>
> map file:
> Error: Invalid initial stack offset
>

I wish I knew why it was saying that or what to patch (and where).

> tdump of RJTEST.OBJ:
> Turbo Dump  Version 4.2.16.1 Copyright (c) 1988, 1996 Borland
> International
>

I'm guessing by 1996 they either complied closer with TIS 1.1 or went their own way. Either way, probably not good for (old 1991) Oberon/M. :-/

> So processing SYS.OBJ with tdstrip didn't help much as the issue of an
> invalid entry point still exists and the blank byte record still gets
> inserted as well as the REGINT (70h) record.
>
> As when I get a chance I will do some more testing/investigation. Re the
> REGINT (70h) record I'm thinking that patching OC.EXE is needed to
> resolve.
Well, probably, but I figured an external tool was easier for now. Besides, it's only the single "main" .OBJ of a project that needs it, not the others.

> [edit: if IMPORT SYS:=SYSTEM; is missing it seems OC defaults to it]
It's apparently trying to be compatible with an earlier release of itself as well as a very-early Oberon System convention. All the "modern" (heh) Oberon compilers I've seen only define SYSTEM, which (like Modula-2) is a built-in module inside the compiler, although you still have to manually import it (and it's a "no no", only uses for non-portable and low-level code).

(OT): One of BWK's complaints about Pascal was that there was no escape, no casts, no type conversions like C had. Modula-2 added a bunch, but that's not typesafe, and they were only supposed to be used in limited cases, not all the time. So they were overused by programmers, hence Wirth removed most of them from Oberon. If you want VAL(), you now have to import SYSTEM. (See OBERNM12.ZIP's OBREPT.ASC for more details.)


MODULE blah;
IMPORT Term,SYSTEM;
VAR s: SET; (* same as M2 BITSET *)
BEGIN
  INCL(s,8); (* 2**8 = 256 *)
  Term.WI(SYSTEM.VAL(INTEGER,s))
END blah.


EDIT: There may be some confusion regarding SYS.OBJ and the internal "module" SYS / SYSTEM. I don't think there is any connection. At least, you must always link with SYS.OBJ, but you don't have to "IMPORT SYSTEM" at all.
Rugxulo

Homepage

Usono,
18.02.2012, 16:56

@ Arjay
 

OMF records - processing SYS.OBJ with tdstrip

Post reply

> I also downloaded the above. First thoughts were that the oberon examples
> you provided were too complex for a good test, e.g. a hello world would
> have been better.

MODULE a;
IMPORT Term,b;
BEGIN
Term.WL(); Term.Wch(22X);
Term.WS("Hello"); b.World; Term.WL()
END a.



MODULE b;
IMPORT Term;
PROCEDURE World*;
BEGIN Term.WS(", world!"); Term.Wch(22X)
END World;
BEGIN END b.


oc b def
oc a
hackomf a.obj
valx a+b+term+sys;
echo (ignore warnings)
a.exe
Arjay

19.02.2012, 10:16

@ Rugxulo
 

OMF records - processing SYS.OBJ with tdstrip

Post reply

For anyone else interested in helping, note the missing step in bold below:

xdef b
> oc b def
> oc a
> hackomf a.obj
> valx a+b+term+sys;
> echo (ignore warnings)
> a.exe
xdef comes with the compiler and generates .dfn files like this from the .MOD source files:
DEFINITION b ;  (* 18 February 2012   16:39 *)

   IMPORT Term;

PROCEDURE World;

END b.


VLX also requires DOS32A
Rugxulo

Homepage

Usono,
19.02.2012, 17:58

@ Arjay
 

OMF records - processing SYS.OBJ with tdstrip

Post reply

> For anyone else interested in helping, note the missing step in bold
> below:
>
> xdef comes with the compiler and generates .dfn files like this from the
> .MOD source files:
You don't need it. With Modula-2, you have to have separate interface (.def) and implementation (.mod) files for each external module you export. The .def is the public spec of how your library is supposed to work. The .mod might not exist publicly, only as an object module (.o) because it's closed source, etc.

Oberon does not separate .def and .mod, presumably because it's more maintenance to keep procedure signatures etc. matched up, so it keeps everything in one file with '*' to export publicly a procedure and (later, Oberon-2 only) '-' for a readonly variable. The symbol file is generated at compile time automatically, and I think the term "browser" is used to generate a .def from the .mod for documentation purposes (or if the .mod isn't open source). E.g. XDS M2/O2 compiler has /xds/def/ob2/ with In.odf, Out.odf, MathL.odf, etc. But they aren't needed to compile.

So, minus one (very weird, pre-standard) Oberon compiler (ULM), I don't think any actually uses separate .def and .mod. Some say having multiple .def files can help as you can expose different amounts of functionality to different clients (even for a single .mod), but obviously others disagree.
Arjay

18.02.2012, 23:37

@ Rugxulo
 

Oberon 1.2 OC (compiler) patch

Post reply

> Unfortunately, it uses at least one problematic ("obsolete") OMF .OBJ
> record in its output: REGINT. This chokes most linkers.

If you patch a single byte at offset CB1Fh from 70h to 88h in OC.EXE, you will no longer need your external patcher. The compilers code changes from:
mov ax,0070h (B80070)

to:
mov ax,0088h (B80088)

Searching OC.EXE for the sequence B80070 in any hex editor will also easily find the required patch point as the sequence only appears once in the file.


For anyone unfamiliar with topic. What we are doing here is changing the OMF REGINT (70h) to a COMENT (88h) record. The REGINT record takes this form:
70h, 00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h

where 00h,00h is a word for the size of the record and the bytes following are the initial register values (6 * word). Fortunately the COMENT record also has a word for record length following the record type byte. So all that happens is the REGINT record becomes a COMENT record:
88h, 00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h

Real world example, this REGINT record:
70 0D 00 01 04 01 01 41 04 05 05 81 04 02 02

becomes a COMENT record:
88 0D 00 01 04 01 01 41 04 05 05 81 04 02 02

This is what Rugxulo utility does after the OBJ file has been created by the compiler, obviously what the patch above does is allow the compiler to be updated so that Rugxulo's external utility isn't required for new OBJ files.


An alternative to patching for OBJ files which removes the redundant record completely via an external tool is to code such a util to do the following:

1)Get filesize of OBJ file to patch
2)Open the OBJ file for writing
3)Read/temporarily store the last 5 bytes of a Oberon generated OBJ file
4)Seeking offset filesize-21 bytes
5)Writing the 5 saved bytes from offset
6)Updating the filesize to be 17 bytes less
7)Closing file

Personally I prefer the OC.EXE patch or Rugxulo method.
Rugxulo

Homepage

Usono,
19.02.2012, 00:54

@ Arjay
 

Oberon/M 1.2 (OMF output) ... die, REGINT, die!

Post reply

> If you patch a single byte at offset CB1Fh from 70h to 88h in OC.EXE, you
> will no longer need your external patcher.
Good to know, but ....

> For anyone unfamiliar with topic. What we are doing here is changing the
> OMF REGINT (70h) to a COMENT (88h) record. The REGINT record takes this
> form:
> 70h,
> 00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h
>
> where 00h,00h is a word for the size of the record and the
> bytes following are the initial register values (6 * word). Fortunately
> the COMENT record also has a word for record length following the record
> type byte. So all that happens is the REGINT record becomes a COMENT
> record:
> 88h, 00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h
>
> Real world example, this REGINT record:
> 70 0D 00 01 04 01 01 41 04 05 05 81 04 02 02
>
> becomes a COMENT record:
> 88 0D 00 01 04 01 01 41 04 05 05 81 04 02 02
>
> This is what Rugxulo utility does after the OBJ file has been created by
> the compiler, obviously what the patch above does is allow the compiler to
> be updated so that Rugxulo's external utility isn't required for new OBJ
> files.
Actually, the real problem is that the COMENT record is how MS and Borland had previously extended the format. So there are many subrecords of the 88h form, so I we have to be really careful not to confuse the linker. And I'm afraid just changing 70h to 88h has the potential to do that. Hence why I just put a bunch of blanks (20h) in there. Perhaps I should've used a different method (e.g. there is a subrecord for copyright, I think, which is just plain text). Yes, comment class 0xDA ("random comment") might've been better, but I don't know (without testing) if it would make things work better (heavily doubt it).

(quoting OMF.PDF from OpenWatcom's FTP server, aka TIS 1.1):

"Note: The presence of any unrecognized subtype causes the linker to generate a fatal error."

"A COMENT record cannot be the first or last record in an object module. (The first record must always be THEADR or LHEADR and the last must always be MODEND.)"

"(Appendix 3, Obsolete Records) When linkers encounter these records, they are free to process them, ignore them, or generate an error."

"(Obsolete Records) 70h REGINT Register Initialization Record This record provides information about the 8086 register/register-pairs: CS and IP, SS and SP, DS and ES. The purpose of this information is for a loader to set the necessary registers for initiation of execution."

> An alternative to patching for OBJ files which removes the redundant record
> completely via an external tool is to code such a util to do the
> following:
What I really should've done was go record by record (sequentially from the top) and remove unnecessary ones, but that was much more complicated and slower, so I didn't bother.

> Personally I prefer the OC.EXE patch or Rugxulo method.
Well, none of it is perfectly ideal.

P.S. ALINK 1.6 works (with a warning), but it's ALINK 1.7 that errors out, sadly. (And yes, you still need HACKOMF there.) Since the default .EXE is RSX bloatware, I just recompiled with DJGPP and used UPX (though I had to delete a spurious line in ALINK.H that said "#define strdup _strdup").
Arjay

19.02.2012, 10:05

@ Rugxulo
 

Oberon/M 1.2 (OMF output) ... die, REGINT, die!

Post reply

> Good to know, but ....
 Doh! I missed the coment sub records in the docs I have been looking at! To be honest I have been patching by hand vs using your util-so missed that.

> What I really should've done was go record by record (sequentially from the
> top) and remove unnecessary ones, but that was much more complicated and
> slower, so I didn't bother.
 No need. I would suggest for external patching that you use the 2nd process I offered up since as you also noted in TIS OMF 1.1:
"A COMENT record cannot be the first or last record in an object module. (The first record must always be THEADR or LHEADR and the last must always be MODEND.

So MODEND should *always* be the last record which from testing it appears OC also sets it to be. After some further investigations last night with working EXE's what I thought might be sensible approach is as follows:
1) Create an external tool which checks the obj header, reads and dumps the REGINT values (CS and IP, SS and SP, DS and ES), moves the MODEND back up the file overwriting the REGINT and updates the OBJ header to "Oberon-M (tm) PC v0.2". Alternatively create a COMENT string record before the MODEND with the values clearly shown, e.g. REGINT values: CS=xx etc
2)Update OC.EXE to not create the REGINT value (I'm almost on that) and change the header generated to "Oberon-M (tm) PC v0.2"


Oberon-M (tm) PC v0.3 might then look like this:
1)Update the external tool to use the values read (or stored in the REGINT coment) and fix a few other issues that from testing I believe also exist
2)Fix those issues in OC.EXE as well


OBJ2ASM is a project worth taking a look at. Unfortunately it doesn't support dumping REGINT fields, it does however support ignoring them and you will find you can recompile the output source to generate a cleaner OBJ.

I have used it for some of my testing along with various other tools, e.g. ODU and readobj.
Back to index page
Thread view  Board view
22773 Postings in 2122 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum