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:
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.
>
>
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.
> 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
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
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.
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>
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
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
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
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.
> 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
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
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
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,
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
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
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
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
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
>
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
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
> 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
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
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
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
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
> 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
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
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
51 matches
Mail list logo