Hi, On Mon, Aug 8, 2011 at 4:51 PM, Kenneth J. Davis <[email protected]> wrote: > > On Aug 8, 2011 5:13 PM, "Bernd Blaauw" <[email protected]> wrote: >> >> I don't think there's any point in trying to add/fix things till a >> 8086-compatible Watcom-based binary can be built with clear building >> instructions.
I'm not sure anybody is trying to add anything, honestly, e.g. extra internal commands. It probably works with 8086, but I'm not sure if they test (or even want to test) that anymore. (I used 8086 shell on my RUFFIDEA disk #2.) >> Getting NASM (which version?!) and Openwatcom ready enough >> on a default extended FreeDOS distro to allow rebuilding kernel and >> FreeCOM would be very pleasant for experimenting/testing/patching purposes I'm not sure most people (even me) want to rebuild the kernel and shell a lot. In particular, rebuilding the shell (even though easy to do) at least "looks" kinda scary complicated (to me). I kinda wish we had a much simpler build process (or even much simpler shell). Well, we do have Centroid's old shell, really really easy to build but somewhat .BAT incompatible and needs DJGPP (386+). Still, I always think, "At least we have that, worst case scenario." That's what FreeDOS-32 used, BTW. (Gcom was interestingly small but non-ANSI C and thus I don't think OpenWatcom liked it, only old [buggy??] Turbo C or whatever. Not sure how useful DOG is, perhaps it's okay, never looked at it too closely.) I know the whole point of the shell is (mostly) to run .BATs, but that's where all the complications come in. Maybe we really do need a shell that does none of that, only the basics (run .EXEs). But I dunno. Anyways, I can't help but think that Rexx (or whatever), via a separate app for scripting, would be a good substitute for .BAT (if you know what you're doing). So, in theory, I could live without .BAT. I know that's not a solution, but just saying .... >> Bart and Jeremy were busy getting that working, and some others managed >> to create a binary as well, though I think that was a 386+ one. Yeah, I built one from SVN so you and I could independently test it (since you had mentioned it): https://sites.google.com/site/rugxulo/FREECOM.ZIP?attredirects=0&d=1 It has two binaries, but I didn't personally test the 8086 (non-XMS) one at all. (In fact, IIRC, I don't think the build process rebuilt KSSF or VSPAWN at all, so I had to do it manually.) > It should be 8086 compatible. Yeah, in a perfect world! ;-) I can't remember why, but I think they always had to leave out some features, hence there was no "universal" shell that would cover 8086 on up with all features (e.g. LOADFIX). I don't know why. The *real* person to ask would be Steffan Kaiser, but I'm fairly sure he hasn't been involved in several years. > Using current ow (1.9 or higher) and current > nasm (2.09 I think) copy the sample batch (.b to .bat) & make (.std to > .mak), edit paths and type build or build xms-swap (i'm not at my computer > to check filenames) and you get a working command.com. Believe it or not, it's easy to build, just kinda complex looking, which is annoying. It looks too fragile, and it makes me think it's too easy to fall apart. Like I said, there was (maybe?) one regression in latest OW build, but other than that, I dunno. It really puts me off, and I'm not much of a programmer (C or otherwise) anyways, so I haven't tried patching / fixing it yet. :-/ > I haven't had time to do much testing nor re familiarize myself enough > to get the localized versions. Ditto, not a huge priority to me (but I'm pretty random). ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
