Hi, On Thu, Aug 4, 2011 at 1:52 AM, Ralf A. Quint <[email protected]> wrote: > At 10:20 PM 8/3/2011, Rugxulo wrote: >>In my defense, I maybe? should've just taken the easy way out and used >>DJGPP (which is 20+ years old, and that's as DOS as it gets, almost >>...). But I didn't see a huge need or advantage. > > Never really was "DOS", always an attempt to prevent those Unix geeks > to have to adjust to DOS.
Well, it's as "DOS" as you can get with a 32-bit DOS extender and POSIX support. >>And BTW, "portable" C is really hard to find, esp. these days when >>"All the world's a VAX!" [32-bit / 64-bit Linux or Windows]. > > C as a language itself is portable, the problem is that there isn't > much portable when it comes (Not sure if this got cut off or not, heh.) I'm not sure I agree. There's just too much crappy C code out there. Worse is that most people force POSIX and fragile / confusing AutoTools on everything. And when code assumes certain-sized ints, GCC, etc. etc., you'd almost be better writing your own from scratch. (If your "configure" is bigger than your total source code size, you've done something wrong!!) > Still don't see what awk and debug have to do with each other, they > are completely different tools, for different purposes. Nothing in common, but one was always installed on DOS, the other always on *nix. > awk is a Unix centric tool for which aren't likely much uses in DOS. It's a general scripting lang, good for text stuff. I think it would be useful. But my point was anything is better than (only) Debug and EXE2BIN !!! ;-) > In all those years that I have been working/programming in DOS, the > only Unix style/originating tools that I really frequently used > was/is grep and diff, but interestingly barely can count the > occasions where I would have used sed for example and certainly never awk... Some (but not all) POSIX tools are indeed sometimes useful. >>BWBASIC just uses doubles for everything, I think. I'm not sure much >>code really relies on MBF, so I wouldn't let it hold you up, IMO. But >>hey, knock yourself out. ;-) > > Every data file that is still out there in old applications that is > using double prec floats and uses BASICA/GW-BASIC/BASCOM or early > QBasic (the compiler that is, not the later interpreter!). Yes, but "most" (??) people won't complain if you personally don't support MBF, at least not initially. BTW, I guess you've seen this: http://support.microsoft.com/kb/35826 > It's just a few years ago where I was called out on a job for another company > to fix an actively used property management still running with > GWBASIC. Too bad I lost my copy of the source code, a tech/programmer > from the original manufacturer (YARDI in Santa Barbara) told me later > that they would love to get their hands on a copy for nostalgic > reasons as they lost all their pre-Windows sources. Backup backup backup. And call me naive, but I consider that an advantage to sharing code, binaries, etc. Somebody else can mirror it for you!! ;-) > And those double prec floats where still reasonable fast, all you > young grasshoppers need to realize that back then, barely a PC had an > x87 style co-processor and the 486, the first CPU to include an > IEEE754 compatible wasn't even on the horizon! Anyone remember Weitek? <LOL> My first PC was a 486 Sx. ;-) >>Okay, I wasn't sure if you were writing it all in pure ASM or not! > > I have been having serious health problem for quite a few years, but > rest assured, I am NOT mentally ill <BEG> ;-) >>Did even QBASIC support MBF? > > No, the QBasic interpreter was based on later versions of the PDS 7 > (fka QB-QuickBasic) compiler and used already the IEEE-754 floating > point format for both single and double prec math... But QB didn't use the x87 at all, apparently, only in their compilers proper. >>Right, but even GPC can convert to/from that. However, I don't see a >>huge need unless you had lots of external data files with that format. > > GPC? What's that? Is that still around? <BEG> Barely. ;-) But it supports your favorite, Wirth Pascal! ;-) > IEEE-754 compatible FPU are part of every Intel CPU since the 486, Correction, 586. ;-) > which was released at a time when Windows was already becoming > mainstay. Windows had an FPU emulator for years. But XP at least requires a Pentium, so that pretty much means FPU must be included. (I'm not even sure if the FPU is "deprecated" or not, at least by MS, as x86-64 seems to prefer SSE2.) > And as FreeBASIC (I assume here that's what you are > referring to as FBC) is a graphics oriented compiler, that's pretty > much understandable that they don't care about anything older. Games > seem to be their main focus anyway, too bad that all of those > attempts to come up with a open source Business Basic > compiler/interpreter died pretty quick. Those are also more evolved > and hard to re-create. Yes, FreeBASIC, and it's just frustrating when old code won't compile. > IEEE-754 came out in '85, and was very quickly adopted by all > compiler/interpreter developers, including Microsoft and Borland. > Borland made IEEE floats the default with Turbo Pascal 4.0 (Turbo C > 1.0) and for their Pascal compilers, included standard support for > the 6 byte "Real" floats through all DOS based compilers and IIRC at > least 'til Delphi 3. > Microsoft just dumped official support with PDS 7 and never supported > MBF for any of the other compilers they offered (don't recall what MS > Cobol and early MS Fortran and oddities like MuMath were using in the > early days. MS Fortran 5.1/PowerStation was the earliest one I can > remember and that was already using IEEE floats and COBOL was likely > to use some BCD style reals... BCD, now there's something most people never used effectively. I think REXX had the right idea, don't have limited precision, but that tends to be slower than static compiles. So I guess it just depends on the app. >>Good luck! I just can't imagine it would be that hard (or crucial), >>but what do I know? ;-) > > I will ask for your assistance when I get around to pick this up > again and get stuck... >:-} Hope I can help! >>To be honest, FBC gets a lot of praise for being QB compatible, but >>it's really not. > > I had a look at it a short while ago and it absolutely isn't. It is > it's own beast all around. QB64 however seemed to be pretty close, > more impressive though if you check out the Mac OS X version for it... ;-) Haven't tried it, but it's "huge" (or so I hear). >>It could still use some cleanups regarding that syntax. But I guess >>so far it's "good enough" >>for most people (or maybe not a priority). Annoying when you find old >>code that you can't rebuild. :-/ > > That was at some point what got me interested in venturing into > starting a GW-BASIC clone. A lot of post on the Internet with people > trying to revive the "good old days when they got started using > computers and wrote their own stuff in GW-BASIC as it came with their > DOS system". Too bad that for example Kindly Rat's GW-BASIC > site/forum closed to being overrun by spammers and he didn't have the > means to move to a better protected setup with that site... I don't understand how supporting less old code and compatibility is seen as an advantage. Companies these days will literally rip out functionality and still have the nerve to call it an "upgrade" (and charge you for it too, natch). Oh well. I still like the idea of emulation / virtualization, though, since it makes (forced, arbitrary, annoying) transitions easier. ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
