Eric, > > That mainly is because Apple is Apple ;-) In DOS, you get very > far with a standard C library, good old OpenWatcom or DJGPP, in > the latter case even similar enough to the Linux GCC and G++ C > and C++ infrastructure to ease porting of things to DOS. As DOS > does not provide GUI, networking or other fancy things as part > of the operating system itself, you can use existing popular C > and other libraries for that (Watt32, Wattcp, SDL, FLTK, ...) > without being bound to a specific choice. The better libraries > of course also come with sample code and documentation :-) Our > distro could include some of the more popular libraries, giving > people a nice starting point for their projects :-) >
That is the whole idea behind the FreeDOS Developer Studio. I know as well as anyone that there are multiple ways to do anything in DOS. Including some of the popular libraries with documentation and sample code either from the library itself or written by us would be great. In addition white papers or articles on best practices. When DOS was king, we had Peter Norton, Andrew Schulman, Jim Pyle, and a host of other great authors that provided information in books (some of which are out of print and most are hard to find) on how to do various things in DOS. I believe there are some very knowledgeable people on this list and we can recreate some of those resources in the form of bite sized articles. I consider you a great resource for example, but there are others on this list. Let’s use long file name support as an example. We have included in FreeDOS, LFNDOS to support the long file names. Since it is open source and we have the code, why not include LFN as a library in the developer studio then someone who is writing an application using long file names can reference that code as a library. I know they can download it themselves and include what they need, but I think that as an example would bring a huge benefit to FreeDOS especially given all the updates made. > Regarding OpenWatcom, NASM, RBIL, Japheth's HX (and JWASM!), I > agree that those are nice things to include :-) Some are rather > large, but I have seen people make compressed basic OpenWatcom > install files that fit on one floppy. It is always hard to get > a good balance in what to include. FreeBasic and FPC etc. are > not very small, but e.g. the set of pre-ported things for DJGPP > is outright huge. You could even have a distro just for DJGPP. > Since OpenWatcom is “open” I was thinking perhaps taking the source and branding it as FreeDOS C based on OpenWatcom, (to give credit) which is what Microsoft did initially with Lattice C via a licensing agreement. The same is true for Free Pascal (if we so desired) albeit with a different name since we can’t call it Free Pascal. > I hope Rugxulo can help you getting that HX download uploaded > to a place where it is easier to get than from the web archive. > The licensing for it (as it relates to FreeDOS) has me wondering if it is even worth the effort. Based on what I read, it sounds good, but if GPL is a factor, we may need to consider something else. I wouldn’t want any hang ups to prevent this from moving forward. > Note that RBIL already tells quite a bit about XMS and EMS, so > having the spec as separate document is just for added detail. > Yes RBIL covers EVERYTHING, but I think having the “official” specification lends more credence to the information we’re providing. If we find that it’s not as useful, it can be removed or referenced via a hyperlink. > In particular, XMS is relatively easy to use even if you do not > have a library for it. Using XMS or EMS with old (C) compilers > can take some effort (memory models and low level stuff to get > into the way, maybe) but to be honest, why take the effort for > manual memory management at all? Simply use any protected mode > aware compiler (DJGPP or a larger memory model in OpenWatcom) > and DPMI and other DOS extender things will magically work for > all your basic needs. Note that when you go that direction, it > will mean that you have to avoid assumptions about direct raw > memory access (screen buffers and such). If you do want that, > you will have to take some explicit efforts, but there is some > sample code on the web to help you out :-) Or just use one of > the existing GUI toolkit libraries to do the work for you :-) > I’m glad we’re finally getting along. :) I was worried for a minute that you weren’t going to like me. Have a wonderful day. Tony ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
