Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

OMF records (Developers)

posted by marcov(R), 20.02.2012, 10:54

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


Complete thread:

Back to the forum
Board view  Mix view
15317 Postings in 1383 Threads, 254 registered users, 22 users online (0 registered, 22 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum