Hi Stas! Thanks a lot for your contribution. Please allow me a few weeks for review, because just right now, I'm moving to a new house and this takes a lot of time. I see you have a lot more experience with DOS, so if this builds and runs with both GCC and LLVM, I'll be happy to merge --- and I'll probably have to rethink the project's name (any suggestions?).
BR, Felix

Hi Felix!

Well, I have to admit that I've deciphered all of
your tricks. :) The first alarm for me was that it works
on dosbox but not on dosemu, unless on dosemu I
enable the CPU emulator. I even naively reported a
bug to dosemu, but the fact that it works with the CPU
emulator better than with the real CPU, made me to
do some debugging. I spent the whole night studying
your project, and here's the report:
dosemu2/dosemu2#197
So now I know this stuff doesn't really work.

As an exercise I reworked the arg0 stuff the
way it can work on real CPU:
stsp@2a3e74f
and I can create a pull request for this too if
you want, but obviously this removes all the
nifty obscurity. :)

So while it is very good that you got this working
at all, the reality is that it hardly gives any any
more than dev86 package already gives.
But thanks for giving me the puzzle to spend the
whole night at disassembling, debugging and deciphering
your nice trick. :)
Let me know if I missed something in my study of it.

Wow, thanks for this great work! I have to admit, I had NO idea about DOS before starting this and just used some online documentation to "get it work". The only things I'm proud of is a) doing once in my life printf() and malloc() on my own .. haha .. I guess others did it better and b) the build system based on GNU make I'm still working on (if I find the time)

So if you actually fixed the b0rked way to get argv[0], I'm happy to merge that as well, thanks a lot! My only goal was to use a modern compiler in a Linux or *BSD environment to create workable DOS .COM binaries. I kind of reached that (far from perfect) by getting my own game to run in dosbox and then abandoned it for lack of time. I see this project isn't of much use to the public, still it's fun and I'm really thankful for your contribution.

So far I looked through your code of this PR and it looks very good. Just allow me the time to do some Q/A testing (just to be sure it doesn't break anything) and then I hope I'm able to understand your argv[0]-fix as well :)

So if you actually fixed the b0rked way to get argv[0], I'm happy to merge that as well, thanks a lot!

This doesn't mean that the compiler works.
I've done it with the inline assembly, so its simply
not useful. The problem is that we have a "small"
memory model here and can't access outside of
the 64Kb with C code.

My only goal was to use a modern compiler in a Linux or *BSD environment to create
workable DOS .COM binaries.

But dev86 can already do that.
What we need is the support for far pointers, and
that's what your project seemingly does (when
accesses the environment segment), but on a closer
look it appears not.

I see this project isn't of much use to the public

Perhaps other people were no as naive as myself
to believe you really access the environment with
the flat pointer. :)
So while you can take my fixes to just run your game
on anything else than dosbox, it unfortunately have
no other value than just to run your game.
I'll create the PR for argv[0] stuff.

well it IS good for something, isn't it? This memory model is an old (and long overcome) PITA. I wasn't aware that segmentation was an issue accessing the environment in DOS. But if you do it using assembly, it helps creating an environment for C programmers .... nevertheless, I'll have a look at "dev86" now, maybe all of this was in vain ... :)

Here's how dev86 does the environment access:
lkundrak/dev86@29dbfca
All in C but playing with segregs by hands nevertheless.

I wasn't aware that segmentation was an issue accessing the environment in DOS.

Because the environment resides in a different
segment than PSP is.

But if you do it using assembly, it helps creating an environment for C programmers

For "small" memory model only, and for that we
already have dev86. The fact that you done it with
clang and gcc is good by itself, of course, but if you
want a real cross-compiler, you can just get openwatcom:
https://github.com/open-watcom/open-watcom-v2
It has full DOS support, far pointers, .exe files - everything.
There is no point in competing dev86 as your project
does, because openwatcom raised the margins very high.

Stas, you're very direct and harsh ;) Still this is ok! I didn't know about "dev86" and I didn't want to use another compiler (watcom), so this is what I came up with. Please don't think about my tiny home-brewn project as "competition", that's not the point. After looking around and not finding what I was looking for, I just decided to do it on my own. And that's all. Sorry for giving you a sleepless night debugging this "crap", but I'm thankful for the explanations as well as the improvements. Expect a merge soon and please understand, this is just a project of a guy curious about old computer architectures (see my C64 stuff as well, hehe). It's not about competition. Thanks again for your contribution :)
BR, Felix

Sorry about being harsh and good luck with
your project. :) The impression that it can be
a competitor to openwatcom was because of
the example code you have there, that is trying
to access the argv0 from C code.

Hi Felix!

I recently explored the 64-bit porting of
DOS programs with clang, and managed
to port freedos:
https://github.com/stsp/fdpp
This was a tough cookie as I had to write
the far pointer emulator and many other
nasty things. But this is only because
freedos uses a lot of assembly and its
far pointers point to the DOS space.
I am quite sure to port other, C-written
DOS progs to 64bit, much fewer efforts
are needed, so I recalled your lib.
My trick with freedos was to use dosemu
when the calls are done to realmode asm.
The rest works in 64bit. So now I think, if
your lib is compiled in 64bit and will use
dosemu for DOS/bios calls, will we get the
cheap porting layer? What do you think?