clang-libdos
clang-libdos copied to clipboard
Zirias
Gcc fixes
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: https://github.com/stsp/dosemu2/issues/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: https://github.com/stsp/clang-libdos/commit/2a3e74f25b5d3c69ebdc5aff95e688bf6ed4c6ff 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: https://github.com/lkundrak/dev86/commit/29dbfca8354315a81f075c3c1fff3557ac8c92e5 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?