Hi again, On Wed, Nov 8, 2017 at 1:23 PM, Ralf Quint <freedos...@gmail.com> wrote: > On 11/8/2017 10:26 AM, Jim Hall wrote: > >> Not sure why DeSmet wasn't well received long ago, but I think this is >> a Good Thing to see. I'd love to see DeSmet included in the next FreeDOS.
It's very minimal, maybe too minimal. It wasn't packaged well. The popular "shareware" version (PCC) back in the day (e.g. on Simtel) was lacking even more: http://reimagery.com/fsfd/bin/Simtel_DOS_1993/simtel/simtel20/MSDOS/C/PCC12C.ZIP > Well, a lot of people here, in particular Arkady (who hasn't been around > for quite some time, who didn't seem to like that it doesn't have a > Borland style IDE) Some people (unlike me) are vastly more productive in IDEs. > and Rugxulo (Mr.GCC, for whom it seemed to be too small) The main .ZIP that I tried didn't even have full ANSI headers, so that put me off. Plus the fact that it's in complete disarray among a billion separate .ZIPs is very confusing. Others are much easier to install without wondering where the missing pieces are. There's no reason to scorn DJGPP, even if it is 386+ DPMI. As far as standards are concerned, it's excellent. And while no huge major work was done in recent years, it's still (!) better "supported" than almost anything else, never lacking on new releases. It's still better to target "standard" than ad hoc, whatever half works. In that regard, DJGPP is more reliable than others. > and a few others made all rather disparaging comments when I made > a post that it had been made Open Source. It's not bad, by any means, even if it doesn't have full ANSI. But seriously, nobody codes for K&R compatibility anymore. That's even rarer than DOS users! We don't want to make things harder than they have to be. >> Since it's GNU GPL, and produces 16bit binaries with the different >> memory models, then this would be a great fit! Like I said before, SmallerC (which is BSD, can rebuild itself, is portable, can cross-compile) is almost certainly "better" (Huge, DPMI, etc) although 386+. > Well, the last part is a bit of a "restriction" (not in my personal > experience though), as it only supports two memory models, Small and > Large. And one thing that a lot of people disliked was that it uses it's > own object format and linker. That was something I was trying to look > into back then with Bill, but then both ran short on available time and > lost contact to Bill. Even SmallerC uses ELF (with extensions). > The main reason why Mark DeSmet used not a standard (well, that was a > bit of a stretch anyway back in the early '80s) .obj format was that the > debugger included was well ahead of what was available on any other C > compiler back in those days, where you might have had to make due with > DOS' good ol' DEBUG... ;-) OMF is too complex for its own good. >> I haven't used this compiler before, but now I'm interested to try it >> out this weekend! > Took you long enough... :-P Just be aware that it is kind of "old time > programming" Don't get your hopes up, Jim. It's not a bad compiler, per se, but it's far from OpenWatcom standards. Seriously, SmallerC is better overall. > What I think makes DeSmet C a good fit is that it will run on FreeDOS > itself just fine, which OpenWatcom doesn't do. (Sigh.) It does run natively, but it requires a DOS extender (DOS4GW or compatible) because it needs lots of RAM. 386-compatible machines are not rare! > And as far as being maintained these days, it is on par with OpenWatcom, Not even close. OpenWatcom is light years ahead. Not to mention that Desmet didn't even get a proper release .ZIP! I'm not complaining, but it's a mess. > which hasn't seen any work at all for 6 1/2 years now (AFAIK) SAP bought Sybase, and the CEO left for Blackberry. So there hasn't been a lot of funding, I suppose? They've too ambitious, too, trying (and succeeding?) to add Win64, Linux64, etc. support, more modern Fortran, etc. Honestly, I haven't kept up very well, so I could be wrong. But what we have now is apparently "good enough". > and even then, DOS support seemed to rather a burden to those few people > that were still working on it, And the attempt to fork it and produce a v2 > branch on GitHub seemed to have had a rather detrimental effect on that > whole compiler project as well. Try the latest snapshot, then: https://sourceforge.net/projects/openwatcom/files/open-watcom-2.0-2017-11-01/ > And it might be in fact much easier to make fixes to the compiler (to > tune in on the often recited but rarely followed Open Source mantra, > particular from the FSF crowd), as it focuses on a single CPU target > (8086/8088), on a single OS (DOS), without having to wade through all > the C++ and multi-platform fluff that comes with all the other compiler > behemoths... Maybe, maybe not. I'm not getting my hopes up. Way easier said than done. Though I do have hope, but some things aren't easy. (But they are easy to some people, so it's far from impossible. We just haven't done it yet.) ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
