Re: [Freedos-devel] Compiling with gcc

2017-12-12 Thread Bart Oldeman
Hi, I finally uploaded a draft (not to be merged yet -- the patch needs to be split in nicer chunks!): https://github.com/bartoldeman/fdkernel/commits/ia16-elf-gcc-draft patch can be seen here: https://github.com/bartoldeman/fdkernel/commit/f873f2052e83fedadfd10b04d79d07246da30bbd Rugxulo wrote:

Re: [Freedos-devel] Compiling with gcc

2017-12-03 Thread Rugxulo
Hi, On Fri, Dec 1, 2017 at 11:00 AM, Bart Oldeman via Freedos-devel wrote: > > On 22 November 2017 at 09:57, Tom Ehlert wrote: >> as a side note: if gcc has no far pointers, its usability as a 16 bit >> compiler is serious limited. > >

Re: [Freedos-devel] Compiling with gcc

2017-12-01 Thread Bart Oldeman via Freedos-devel
Hi Tom, On 22 November 2017 at 09:57, Tom Ehlert wrote: > as a side note: if gcc has no far pointers, its usability as a 16 bit > compiler is serious limited. There is one now, finally, since T.K. Chia started working on the IA16 port in June.

Re: [Freedos-devel] Compiling with gcc

2017-11-22 Thread Tom Ehlert
> I didn’t read most of the messages in this thread. So, forgive me > if I have completely missed something important. > Why allocate any memory for reading the environment variables? > Why not just examine them in place? They are just Null terminated strings. they are just zero terminated

Re: [Freedos-devel] Compiling with gcc

2017-11-22 Thread Tom Ehlert
Hallo Herr Andreas K. Foerster, am 22. November 2017 um 15:25 schrieben Sie: > Am Mittwoch, dem 22. Nov 2017 schrieb Tom Ehlert: >> > Are there any documented limits for environment variables in DOS? >> no. >> >> > My implementation uses a static buffer. So the content changes with >> > every

Re: [Freedos-devel] Compiling with gcc

2017-11-22 Thread Jerome Shidel
I didn’t read most of the messages in this thread. So, forgive me if I have completely missed something important. Why allocate any memory for reading the environment variables? Why not just examine them in place? They are just Null terminated strings.

Re: [Freedos-devel] Compiling with gcc

2017-11-22 Thread Andreas K. Foerster
Am Mittwoch, dem 22. Nov 2017 schrieb Tom Ehlert: > > Are there any documented limits for environment variables in DOS? > no. > > > My implementation uses a static buffer. So the content changes with > > every call to getenv. This is explicitly allowed by the standard. > > > I don't want to

Re: [Freedos-devel] Compiling with gcc

2017-11-22 Thread Tom Ehlert
> Are there any documented limits for environment variables in DOS? no. > My implementation uses a static buffer. So the content changes with > every call to getenv. This is explicitly allowed by the standard. > I don't want to make the buffer too large though, did you ever hear about dynamic

Re: [Freedos-devel] Compiling with gcc

2017-11-21 Thread Robert Riebisch
Hi, > Additionally to Ralf's answer this book might be handy for the future: > http://www.borncity.de/Library/DOSProgHB.PDF (in German only) > It's not "the best", but fairly okay. This info is also in http://cd.textfiles.com/cream06/program/dosref34.zip -> CHAPTER.006 -> look for "DOS PROGRAM

Re: [Freedos-devel] Compiling with gcc

2017-11-20 Thread Ralf Quint
On 11/20/2017 1:55 PM, Robert Riebisch wrote: > Additionally to Ralf's answer this book might be handy for the future: > http://www.borncity.de/Library/DOSProgHB.PDF (in German only) > It's not "the best", but fairly okay. > > Robert Riebisch Nice one, thanks. Without seeing the actual front

Re: [Freedos-devel] Compiling with gcc

2017-11-20 Thread Robert Riebisch
Hi Andreas, > Are there any documented limits for environment variables in DOS? > > My implementation uses a static buffer. So the content changes with > every call to getenv. This is explicitly allowed by the standard. > > I don't want to make the buffer too large though, since space > is so

Re: [Freedos-devel] Compiling with gcc

2017-11-19 Thread Ralf Quint
On 11/19/2017 8:16 AM, Andreas K. Foerster wrote: > > Are there any documented limits for environment variables in DOS? > > My implementation uses a static buffer. So the content changes with > every call to getenv. This is explicitly allowed by the standard. > > I don't want to make the buffer

Re: [Freedos-devel] Compiling with gcc

2017-11-19 Thread Andreas K. Foerster
Am Sonntag, dem 19. Nov 2017 schrieb Andreas K. Foerster: > Am Samstag, dem 18. Nov 2017 schrieb Joe Forster/STA: > > > > By the way, can anybody tell me, how to access environment variables, > > > when the compiler doesn't support it? (no getenv() and environ=NULL) > > > > Use INT 21h, AH=62h

Re: [Freedos-devel] Compiling with gcc

2017-11-18 Thread Andreas K. Foerster
Am Samstag, dem 18. Nov 2017 schrieb Joe Forster/STA: > > By the way, can anybody tell me, how to access environment variables, > > when the compiler doesn't support it? (no getenv() and environ=NULL) > > Use INT 21h, AH=62h to get the PSP segment and then see the word at offset > 002Ch for the

Re: [Freedos-devel] Compiling with gcc

2017-11-18 Thread Ralf Quint
On 11/18/2017 9:34 AM, Andreas K. Foerster wrote: > > By the way, can anybody tell me, how to access environment variables, > when the compiler doesn't support it? (no getenv() and environ=NULL) > Attached is a file from a PD snippets collection to get (and set, with the usual limitations) the

Re: [Freedos-devel] Compiling with gcc

2017-11-18 Thread Andreas K. Foerster
Am Samstag, dem 18. Nov 2017 schrieb David McMackins: > But isn't bcc proprietary, thereby undermining the entire goal here? Oh, I forgot that there is also a proprietary compiler which uses the same abbreviation. ;-) I meant Bruce's C-Compiler, which is already included in FreeDOS. It was

Re: [Freedos-devel] Compiling with gcc

2017-11-18 Thread Rugxulo
Hi, On Sat, Nov 18, 2017 at 12:53 PM, Ralf Quint wrote: > On 11/18/2017 10:46 AM, David McMackins wrote: >> But isn't bcc proprietary, thereby undermining the entire goal here? >> > Contrary to the believes of the FSF, the world is full of C compilers In fairness, GCC is

Re: [Freedos-devel] Compiling with gcc

2017-11-18 Thread Joe Forster/STA
Hi Andreas, By the way, can anybody tell me, how to access environment variables, when the compiler doesn't support it? (no getenv() and environ=NULL) Use INT 21h, AH=62h to get the PSP segment and then see the word at offset 002Ch for the segment of environment variables. (See Table 01378

Re: [Freedos-devel] Compiling with gcc

2017-11-18 Thread Ralf Quint
On 11/18/2017 9:34 AM, Andreas K. Foerster wrote: > By the way, can anybody tell me, how to access environment variables, > when the compiler doesn't support it? (no getenv() and environ=NULL) > Well, yes, you have to pretty much write those functions yourself by accessing the MCB (Memory Control

Re: [Freedos-devel] Compiling with gcc

2017-11-18 Thread Ralf Quint
On 11/18/2017 10:46 AM, David McMackins wrote: > But isn't bcc proprietary, thereby undermining the entire goal here? > Contrary to the believes of the FSF, the world is full of C compilers and he is talking about a different one than the one that crosses your mind... Ralf --- This email has

Re: [Freedos-devel] Compiling with gcc

2017-11-18 Thread David McMackins
But isn't bcc proprietary, thereby undermining the entire goal here? Happy Hacking, David E. McMackins II Supporting Member, Electronic Frontier Foundation Associate Member, Free Software Foundation (#12889) www.mcmackins.org www.delwink.com www.eff.org www.gnu.org www.fsf.org On 11/18/2017

Re: [Freedos-devel] Compiling with gcc

2017-11-18 Thread Andreas K. Foerster
Am Sonntag, dem 29. Okt 2017 schrieb Jim Hall: > That said, I'd love to see other tools become part of FreeDOS. If > there was a DOS-native GCC that could generate 16-bit binaries in the > different memory models, I'm all for that. The problem is not only in the code creation, but you also need

Re: [Freedos-devel] Compiling with gcc

2017-11-03 Thread Louis Santillan
On Sun, Oct 29, 2017 at 9:20 PM, Steve Nickolas wrote: > On Sun, 29 Oct 2017, Jim Hall wrote: > >> That said, I'd love to see other tools become part of FreeDOS. If >> there was a DOS-native GCC that could generate 16-bit binaries in the >> different memory models, I'm all for

Re: [Freedos-devel] Compiling with gcc

2017-11-01 Thread Rugxulo
Hi, On Sun, Oct 29, 2017 at 9:36 PM, Ralf Quint wrote: > On 10/29/2017 3:04 PM, Jim Hall wrote: >> > IMHO, screw the FSF. Seriously. It has turned into one of those almost > religious fanatics entities that pretend to be "more pious than the > pope" (a translation of a

Re: [Freedos-devel] Compiling with gcc

2017-10-31 Thread Steve Nickolas
On Tue, 31 Oct 2017, Jim Hall wrote: And in fact, others have managed to run Windows on FreeDOS. That's quite an accomplishment. I actually did it once years ago (386 mode even, and I was following someone else's guide). Wasn't very stable or reliable, but that it worked at all was a sort

Re: [Freedos-devel] Compiling with gcc

2017-10-31 Thread Steve Nickolas
On Tue, 31 Oct 2017, Tom Ehlert wrote: what do you mean by that? (at least most) MS software should work as well. we actually took a couple of MS utilities (think chkdsk, MSD, ...) to verify compatibility. Windows for Workgroups 3.11, the ultimate torture test that, last I checked, only

Re: [Freedos-devel] Compiling with gcc

2017-10-31 Thread Eric Auer
Hi David, > I'm the one who started this mail chain. It started as a mere inquiry > (on behalf of a friend, really) as to whether gcc would be a viable > compiler. I got my answer: it's not. when you interpret GCC as DJGPP, then DJGPP is a pretty nice compiler for larger DOS programs: It helps

Re: [Freedos-devel] Compiling with gcc

2017-10-31 Thread Jim Hall
On Tue, Oct 31, 2017 at 1:12 PM, Tom Ehlert wrote: > > Slight it as I may, at least FreeDOS works in the vast majority of usage > > cases that don't involve software published by Microsoft, > > what do you mean by that? (at least most) MS software should work as > well. >

Re: [Freedos-devel] Compiling with gcc

2017-10-31 Thread Tom Ehlert
Hallo Herr Steve Nickolas, am Dienstag, 31. Oktober 2017 um 19:03 schrieben Sie: > On Tue, 31 Oct 2017, Tom Ehlert wrote: >> Hallo Herr Steve Nickolas, >> >> am Dienstag, 31. Oktober 2017 um 17:47 schrieben Sie: >> >>> On Tue, 31 Oct 2017, Tom Ehlert wrote: >> you could help Christian to

Re: [Freedos-devel] Compiling with gcc

2017-10-31 Thread Steve Nickolas
On Tue, 31 Oct 2017, Tom Ehlert wrote: Hallo Herr Steve Nickolas, am Dienstag, 31. Oktober 2017 um 17:47 schrieben Sie: On Tue, 31 Oct 2017, Tom Ehlert wrote: you could help Christian to bring RxDOS into a usable state (and report how much fat this saves with how much work) good luck

Re: [Freedos-devel] Compiling with gcc

2017-10-31 Thread Tom Ehlert
Hallo Herr Steve Nickolas, am Dienstag, 31. Oktober 2017 um 17:47 schrieben Sie: > On Tue, 31 Oct 2017, Tom Ehlert wrote: >> you could help Christian to bring RxDOS into a usable state (and >> report how much fat this saves with how much work) >> good luck though, as I don't expect this to ever

Re: [Freedos-devel] Compiling with gcc

2017-10-31 Thread Steve Nickolas
On Tue, 31 Oct 2017, Tom Ehlert wrote: you could help Christian to bring RxDOS into a usable state (and report how much fat this saves with how much work) good luck though, as I don't expect this to ever happen. just surprise me ;) Has RxDOS even been touched this millennium? O_o -uso.

Re: [Freedos-devel] Compiling with gcc

2017-10-31 Thread Tom Ehlert
> The other alternative would be to ditch C altogether and go with ASM > (since I *know* there's assemblers that fit the bill), but it's way too > late to do THAT, and I don't think anyone who has the capability to do so > is bothered enough to go that far (though to be fair, if someone WERE to

Re: [Freedos-devel] Compiling with gcc

2017-10-30 Thread Steve Nickolas
I'll bite again... On Mon, 30 Oct 2017, David McMackins wrote: I never said that we should reject FreeDOS because it lacks an FSF-approved compiler. There are some who would (I think Debian puts it into a separate category because of the compiler issue...and Debian tends to be even more

Re: [Freedos-devel] Compiling with gcc

2017-10-30 Thread David McMackins
On 10/29/2017 11:00 PM, Ralf Quint wrote: > Well, I happily invite you to provide us with a free development tool > that will work in our case and fits your (IMHO) overly idealistic POV. I'm the one who started this mail chain. It started as a mere inquiry (on behalf of a friend, really) as to

Re: [Freedos-devel] Compiling with gcc

2017-10-29 Thread Steve Nickolas
On Sun, 29 Oct 2017, Jim Hall wrote: Without getting in the *Free Software* v *Open Source Software* debate, I believe FreeDOS should be available to everyone, and should never become closed source. For that reason, I contributed my FreeDOS work under the GNU GPL. I personally use the latter,

Re: [Freedos-devel] Compiling with gcc

2017-10-29 Thread Ralf Quint
On 10/29/2017 8:02 PM, David McMackins wrote: > On 10/29/2017 09:36 PM, Ralf Quint wrote: >> MS/PC-DOS predates the FSF, GPL and the Stallman virus. DOS itself (in >> pretty much any incarnation, up to and including FreeDOS itself) has >> always been depending on "less-than free" development

Re: [Freedos-devel] Compiling with gcc

2017-10-29 Thread David McMackins
On 10/29/2017 09:36 PM, Ralf Quint wrote: > MS/PC-DOS predates the FSF, GPL and the Stallman virus. DOS itself (in > pretty much any incarnation, up to and including FreeDOS itself) has > always been depending on "less-than free" development tools. So what? UNIX was 100% proprietary when it was

Re: [Freedos-devel] Compiling with gcc

2017-10-29 Thread Ralf Quint
On 10/29/2017 3:04 PM, Jim Hall wrote: > > Without getting in the *Free Software* v *Open Source Software* > debate, I believe FreeDOS should be available to everyone, and should > never become closed source. For that reason, I contributed my FreeDOS > work under the GNU GPL. I don't think that

Re: [Freedos-devel] Compiling with gcc

2017-10-29 Thread Jim Hall
On Fri, Oct 27, 2017 at 3:45 PM, Rugxulo wrote: > Jim Hall is a serious proponent of Free Software. I'm a pretty big fan > myself. He has always recommended OW (Sybase v1, "OSI") and NASM > ("BSD" 2-clause). I don't see the need to put obstacles in the path of > future users

Re: [Freedos-devel] Compiling with gcc

2017-10-27 Thread Rugxulo
Hi, On Fri, Oct 27, 2017 at 7:31 AM, Tom Ehlert wrote: > >> On Fri, 27 Oct 2017, Rugxulo wrote: > >> All of the TurboC ports should be deprecated in lieu of OpenWatcom >> (or, better yet, DJGPP). > it's not a TurboC port. in 2001 TurboC was the free (as in beer) compiler >

Re: [Freedos-devel] Compiling with gcc

2017-10-27 Thread Rugxulo
Hi, On Fri, Oct 27, 2017 at 10:44 AM, Andreas K. Foerster wrote: > > You can also use [BCC/Dev86] on a GNU/Linux system as a cross compiler. > Use the option -Md to produce DOS binaries. > (Note: the version in FreeDOS is older and doesn't have the program > unprotoize

Re: [Freedos-devel] Compiling with gcc

2017-10-27 Thread Andreas K. Foerster
Hello, if you are looking for a free (GPLv2) compiler that's included in FreeDOS, have a look at the package BCC (Bruce's C compiler). It can produce binaries in the small or tiny model, ie. you are limited to 64kB of code + 64kB of data or 64kB for everything. It only supports ancient K syntax

Re: [Freedos-devel] Compiling with gcc

2017-10-27 Thread Tom Ehlert
> On Fri, 27 Oct 2017, Rugxulo wrote: > Tiny and Small are better than nothing. AFAIK, DOS-C used to use Small > model. FreeCOM also uses Small model too, IIRC. both FreeCOM and Kernel tell the compiler to use the small model for all default assignments of segments, and use (a lot of) explicit

Re: [Freedos-devel] Compiling with gcc

2017-10-26 Thread Steve Nickolas
On Fri, 27 Oct 2017, Rugxulo wrote: Tiny and Small are better than nothing. AFAIK, DOS-C used to use Small model. FreeCOM also uses Small model too, IIRC. Does it? To get what I wanted out of my own command shell required me to use Compact (though that thing NEVER worked right). All of

Re: [Freedos-devel] Compiling with gcc

2017-10-26 Thread Rugxulo
Hi, On Thu, Oct 26, 2017 at 12:37 PM, Jim Hall wrote: >> On Thu, 26 Oct 2017, David McMackins wrote: >> >>> I have been informed that gcc has a -m16 flag that actually outputs >>> binaries that can run in 16-bit mode. Is there then anything stopping >>> FreeDOS from being

Re: [Freedos-devel] Compiling with gcc

2017-10-26 Thread Mark Olesen
GCC is not capable of producing pure 16-bit binaries even with -m16. On Thu, Oct 26, 2017 at 11:37 AM, Jim Hall wrote: > > On Thu, 26 Oct 2017, David McMackins wrote: > > > >> I have been informed that gcc has a -m16 flag that actually outputs > >> binaries that can run in

Re: [Freedos-devel] Compiling with gcc

2017-10-26 Thread Ralf Quint
On 10/26/2017 5:51 AM, David McMackins wrote: > I have been informed that gcc has a -m16 flag that actually outputs > binaries that can run in 16-bit mode. Is there then anything stopping > FreeDOS from being compiled fully with gcc? Hell no. For starters, gcc is a Linux/Unix based compiler, it

Re: [Freedos-devel] Compiling with gcc

2017-10-26 Thread Jim Hall
> On Thu, 26 Oct 2017, David McMackins wrote: > >> I have been informed that gcc has a -m16 flag that actually outputs >> binaries that can run in 16-bit mode. Is there then anything stopping >> FreeDOS from being compiled fully with gcc? >> >> If not, why are we still using Watcom? On Thu, Oct

Re: [Freedos-devel] Compiling with gcc

2017-10-26 Thread Steve Nickolas
On Thu, 26 Oct 2017, David McMackins wrote: I have been informed that gcc has a -m16 flag that actually outputs binaries that can run in 16-bit mode. Is there then anything stopping FreeDOS from being compiled fully with gcc? If not, why are we still using Watcom? Pretty sure that GCC, if it

[Freedos-devel] Compiling with gcc

2017-10-26 Thread David McMackins
I have been informed that gcc has a -m16 flag that actually outputs binaries that can run in 16-bit mode. Is there then anything stopping FreeDOS from being compiled fully with gcc? If not, why are we still using Watcom? Happy Hacking, David E. McMackins II Associate Member, Free Software