Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

OMF records - processing SYS.OBJ with tdstrip (Developers)

posted by Rugxulo(R) Homepage E-mail, USA, 19.02.2012, 17:58

> 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.

 

Complete thread:

Back to the forum
Board view  Mix view
13760 Postings in 1217 Threads, 206 registered users, 14 users online (1 registered, 13 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum