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. >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 >FreeDOS "BASE" is strictly mimicking MS-DOS core stuff they included. >But it lacks DOSSHELL or QBASIC, at least in "BASE". So, for average >scripting, while *nix has sh and awk, all we have is Debug! We don't >even have BWBASIC to fully rely upon. That was my point, we're at a >small disadvantage since we can't assume everyone has BWBASIC >installed (whereas QBASIC was common enough to be occasionally >utilized in Timo Salmi's .BAT FAQ). So include BWBASIC, that's what we currently have and that's as good as it gets, at least for now... Still don't see what awk and debug have to do with each other, they are completely different tools, for different purposes. Debug was a part of original DOS and I think the clone that we have is a very good one, so just include it. EXE2BIN doesn't have that many real uses these days anymore where the compiler that are available can make COM programs at least at will, and there's probably not many people around that would need to create ROMable binaries from compilers that only create EXEs for certain memory models around either. If there's a workable version we can include, "just do it"... ;-) awk is a Unix centric tool for which aren't likely much uses in DOS. That it saw/probably still sees a lot of uses in Unix/Linux environments is simply due to the fact that "back in those days", there weren't much interpreters like BASICA/GWABASIC in DOS around that could be used to do some more advanced text processing (for still "quick and dirty" kind of jobs) and using tools like awk (or sed, m4, etc) was the way it was dealt with in the Unix world back then. Someone wrote a more or less small tool with a (slowwwww) C compiler and from then on used it to call upon it to do certain task in shell scripts. As far as FreeDOS is concerned, IMHO awk has no place in a "BASE" package, that would be rather something for an add-on... 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... >I just meant, "Look, even Gates wrote some real BASIC for public >consumption", so it has some historic value to some people, if not >(also) technical or nostalgic. He did also quite a bit of work on the ALTAIR BASIC, nobody's going crazy about that but than that's not something that Jobs will wag his tail about... ;-) > > But then DONKEY.BAS was never meant to be an epitome of BASIC > > graphics programming (which as far as the original IBM PC was > > concerned was limited to 320x200 pixel in 4 (fixed)colors (black, > > white, purple, cyan) on a CGA... > >No, of course not, but it's far from embarrassing. I'm sure we've all >seen and written worse. It's just a (semi-) famous example that I >thought was interesting, esp. since the IBM PC turns 30 next week >(Aug. 12). Is it, really? Read the story about how this came about again, it's not that this a long term project but some QaD job they did under bad conditions over night to pretty much just prove a point. I think this is a typical case where things are just blown out of proportion... >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!). 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. 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> > >>It can't be *that* impossible. Still, I'm not sure I'd be able to help > >>much. (What language are you writing in? Assembly? C?) > > > > A mix of C and assembler. I am/was aiming for "working like" more > > than for creating a "binary copy", so most interpreter logic and > > line/screen editor function is in C, most "runtime library" stuff > > would be linked-in assembler. I also started to maintain an a memory > > array which holds all those known PEEK and POKE addresses that where > > widely used, which isn't without a challenge either in terms of > > staying compatible.. > >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... > I haven't used it but barely recently, >but I seem to remember that even it lacked some (minor?) compatibility >to GW-BASIC. I never really got into using Qbasic, but IIRC, mainly things that had advanced technologically, like sound and graphics as well as changes to the file handling... > > Most float capable programming languages had their own float formats > > back in the early days, which at least for anything above 4 byte > > floats (single precision) where not compatible with each other. Like > > Turbo Pascal 1.0-3.0's 6 byte Real format for example, > >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> >Of course, FPUs were slow and expensive back in the day, whereas every >Pentium 1 cpu on up has had one (except some embedded chips). So they >probably just took the easy / fast way out by "inventing" their own >(limited?) format. I'm not sure even "standard" Pascal had any >specific range for floating point values. (Note that because FPUs are >everywhere nowadays, there is less incentive for people like FBC to >cater to older cpus, e.g. their runtime always assumes an FPU, sadly. >I had to patch it for DOS386's FBMD5 just so it wouldn't need a >"bloaty" emulator lib, heh.) IEEE-754 compatible FPU are part of every Intel CPU since the 486, which was released at a time when Windows was already becoming mainstay. 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. 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... > > or those from DR's CBASIC. Or such main staples of early computing > > like Commodore's C64/VC-20, CBM's or Trash-80s and clones, Sinclair's, > > BBC, etc... That requires quite a bit of reverse-engineering and > testing to say > > the least... > >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... >:-} >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... ;-) >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... Ralf ------------------------------------------------------------------------------ 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
