Hi,
On Tue, Apr 2, 2019 at 4:51 AM Tom Ehlert wrote:
>
> > On Fri, Feb 22, 2019 at 5:44 PM Rugxulo wrote:
> >>
> >> I also did some minor fixes to my (unpublished, prerelease 0.7) MetaDOS.
>
> > Nobody said anything, so I didn't worry about it. But I did (barely)
> > just do minor fixes and
> On Fri, Feb 22, 2019 at 5:44 PM Rugxulo wrote:
>>
>> I also did some minor fixes to my (unpublished, prerelease 0.7) MetaDOS.
>> (If anybody cares, I could just upload it, but it's still not perfect,
>> obviously.
>> FYI, "Newwget" isn't publicly available anymore, so I'm partially
Hi,
On Fri, Feb 22, 2019 at 5:44 PM Rugxulo wrote:
>
> I also did some minor fixes to my (unpublished, prerelease 0.7) MetaDOS.
> (If anybody cares, I could just upload it, but it's still not perfect,
> obviously.
> FYI, "Newwget" isn't publicly available anymore, so I'm partially preferring
>
Hi Bart,
> sbrk is a little deceiving here since it just administrates a
> high-water mark and does not allocate memory from DOS:
> old:
> https://github.com/tkchia/newlib-ia16/blob/e7c08882834a41d848698a19deae49089c2dab17/libgloss/ia16/dos-sbrk.c
> which only returned NULL if heap ptr went
Hello Bart,
new (just changed by TK Chia)
https://github.com/tkchia/newlib-ia16/blob/newlib-2_4_0-ia16-tkchia/libgloss/ia16/dos-sbrk.c
malloc returns NULL when the end of the heap is reached but this is
not always checked properly in freecom, but at least it does not grow
into the stack any
Hi Tom,
sbrk is a little deceiving here since it just administrates a
high-water mark and does not allocate memory from DOS:
old:
https://github.com/tkchia/newlib-ia16/blob/e7c08882834a41d848698a19deae49089c2dab17/libgloss/ia16/dos-sbrk.c
which only returned NULL if heap ptr went beyond 64K (the
Hi Bart,
> I tried to limit heap grow a bit using a patch to nanomalloc
> https://gist.github.com/f45f2874b16afd8957d019db6182067e
> which basically takes any free block at the end into account when it
> needs to grow the heap via sbrk, so it does not leave a hole there.
using sbrk() inside
Bart,
> you are (in your words) 110% right.
> At the time I had fixed the stack offenders but got lost in debugging
> adapting your stack-checking patch to other compilers (it actually
> checks the heap too, if heap grows to stack).
heap growing to stack *without stack check enabled) is a REAL
Hello Bart,
thanks for offering to help. I now pushed a GCC-portable version of
Tom's stack check to freecom's git:
https://github.com/FDOS/freecom
However if you try to compile it you'll see once you run it that it
says 0 stack left quite quickly. The reason is not the stack (there is
plenty)
Hi TK,
thanks for offering to help. I now pushed a GCC-portable version of
Tom's stack check to freecom's git:
https://github.com/FDOS/freecom
However if you try to compile it you'll see once you run it that it
says 0 stack left quite quickly. The reason is not the stack (there is
plenty) but
Hi,
On Fri, Feb 22, 2019 at 7:03 AM Tom Ehlert wrote:
>
> > so in the end the issue is a stack overflow:
>
> after 5 months since this (16 year old) bug was found, there is still
> no official command.com for everybody else to test.
>
> there are also 3 located, and easy fixable bugs in the
Hello Bart Oldeman,
The OW version looked reasonably stable, the GCC version still ran
into some issues if I remember correctly. Hopefully I can get around
uploading a new prerelease sometime this weekend, and make it the real
release if it works ok.
Do let me know if I might be of any help,
Tom,
you are (in your words) 110% right.
At the time I had fixed the stack offenders but got lost in debugging
adapting your stack-checking patch to other compilers (it actually
checks the heap too, if heap grows to stack).
The OW version looked reasonably stable, the GCC version still ran
into
Hi Bart, (and all the other maintainers)
> so in the end the issue is a stack overflow: filenames on the stack
> overflow into a const buffer used by strtok. I had raised it from 2K
> to 4K back in January but that is not enough.
> Since Blair Campbell's LFN work in 2006 cmd_rename() which
Hi Bart,
1st, I hope you live in a different timezone.
at 4:07 we all should be in bed ;)
> so in the end the issue is a stack overflow:
nice find :))
> filenames on the stack
> overflow into a const buffer used by strtok. I had raised it from 2K
> to 4K back in January but that is not
Hi Tom,
so in the end the issue is a stack overflow: filenames on the stack
overflow into a const buffer used by strtok. I had raised it from 2K
to 4K back in January but that is not enough.
Since Blair Campbell's LFN work in 2006 cmd_rename() which calls
fillFnam() together use at least 13
Hi Tom,
the issue is that OW strtok() detects characters in the set using a
bitmask and uses an 8 char lookup table called _Bits (__Bits in the
mapfile) which normally has this
01 02 04 08 10 20 40 80
(in hex) A printf confirms that this table is overwritten, so there is
a buffer overflow
Hi Tom,
strtok's source can be browsed here:
http://perforce.openwatcom.org:4000/@md=d=//depot/openwatcom/bld/clib/string/c/=//depot/openwatcom/bld/clib/string/c/strtok.c=33595=sgp@//depot/openwatcom/bld/clib/string/c/strtok.c
Bart
___
Freedos-devel
Hi Bart,
at least one bug located in freecom-watcom:
run
TESTS KE2041
will stop after a short while (this IS helpful)
with an error.
now
a:
COPY COMMAND.COM TEST
-->
unable to open file 'command'
after some liberal sprinkling of printf()'s,
static int addSource(char
Hi Tom,
interestingly picoc is still buggy after I disable XMSinit() and
XMSexec() in the xms-swap build. This makes debugging a bit easier now
that that code is eliminated.
On Tue, 23 Oct 2018 at 19:12, Bart Oldeman wrote:
>
> Hi Tom,
>
> the big one is built with xms-swap, yours without. I get
Hi Tom,
the big one is built with xms-swap, yours without. I get 82758 also
without xms-swap.
So it looks like something in the swap code is still buggy then ...
Bart
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
On 10/23/2018 2:05 PM, Robert Riebisch wrote:
Hi Ralf,
barts freecom has length 84756
myfreecom has length 82758 (without UPX)
should this not be identical?
One would expect so. But a two byte difference, and the bug in one
Not two bytes: 84756 - 82758 = 1998 bytes
Cheers
Robert
Hi Ralf,
>> barts freecom has length 84756
>> myfreecom has length 82758 (without UPX)
>>
>> should this not be identical?
> One would expect so. But a two byte difference, and the bug in one
Not two bytes: 84756 - 82758 = 1998 bytes
Cheers
Robert
--
+++ BTTR Software +++
On 10/23/2018 6:05 AM, Tom Ehlert wrote:
now things become strange.
I tried to reproduce and fix the bugs reported on oct 19.
when I replace freecomW as compiled by Bart by a
watcom compiled by me, the bugs vanish.
compiled by wcc 1.9
barts freecom has length 84756
myfreecom has length
Hi Tom,
> when I replace freecomW as compiled by Bart by a
> watcom compiled by me, the bugs vanish.
> compiled by wcc 1.9
> barts freecom has length 84756
> myfreecom has length 82758 (without UPX)
> should this not be identical?
yes they should be identical, as I also used wcc 1.9. I'll
now things become strange.
I tried to reproduce and fix the bugs reported on oct 19.
when I replace freecomW as compiled by Bart by a
watcom compiled by me, the bugs vanish.
compiled by wcc 1.9
barts freecom has length 84756
myfreecom has length 82758 (without UPX)
should this not be
Hi,
On Fri, Oct 19, 2018 at 11:04 PM Rugxulo wrote:
>
> > *
> > restart machine.
> >TESTS NASMWAT
> > all 3 report 'bad command or file name "tar.exe", but proceed
> > in the end, all 3 fail in identical way.
>
> Yeah, it's
> I really wasn't expecting you to directly run all "tests".
even if it's probably relevant what they do and how they do what they
do, for my purpose this was (and is) irrelevant.
whatever they do, I took them as a big test case for freecom builds,
in particular to avoid new introduced bugs.
Hi again,
On Fri, Oct 19, 2018 at 10:22 PM Rugxulo wrote:
>
> On Fri, Oct 19, 2018 at 10:59 AM Tom Ehlert wrote:
> >
> > run
> >TESTS JED
> >
> > this should download a lot of stuff, build JED, and keep the machine busy
> > for 10 minutes.
>
> I'd have to run that test again
Using old
Hi,
N.B. All tests I'm re-running below are using old stock 2006 TC build
of FreeCOM. I'm just telling you the times and success for rough
comparison of what I'm seeing and what is normally expected (by me).
BTW, "tests /t oberon16" succeeds and only takes 29 secs.
On Fri, Oct 19, 2018 at 12:16
Hi,
On Fri, Oct 19, 2018 at 10:59 AM Tom Ehlert wrote:
>
> > Here's the DropBox link (again), in case it wasn't obvious:
>
> > * https://www.dropbox.com/s/6whjgmb9xhdgw29/metados-0.7.zip?dl=0
>
> how in god name would that be obvious?
I already mentioned it explicitly. In fact, you asked me
> Here's the DropBox link (again), in case it wasn't obvious:
> * https://www.dropbox.com/s/6whjgmb9xhdgw29/metados-0.7.zip?dl=0
how in god name would that be obvious?
are we all required to note all your more or less old emails?
anyway, I downloaded this, and replaced the 32-bit
> Here's the DropBox link (again), in case it wasn't obvious:
> * https://www.dropbox.com/s/6whjgmb9xhdgw29/metados-0.7.zip?dl=0
how in god name would that be obvious?
are we all required to note all your more or less old emails?
anyway, I downloaded this, and replaced the 32-bit
Hi,
On Thu, Oct 11, 2018 at 7:02 AM Tom Ehlert wrote:
>
> on 12. September 2018 um 03:14 schrieben Sie:
>
> > On Tue, Sep 11, 2018 at 8:12 AM Tom Ehlert wrote:
> >>
> >> > The GNUC version seems to mostly work,
>
> > I didn't quite have the time or energy to test TC or Watcom builds
> > yet.
>
Hi Rugxulo,
on 12. September 2018 um 03:14 schrieben Sie:
> On Tue, Sep 11, 2018 at 8:12 AM Tom Ehlert wrote:
>>
>> > The GNUC version seems to mostly work,
> I didn't quite have the time or energy to test TC or Watcom builds
> yet.
often this is not needed; bugs in one version of FreeCOM
On Fri, 14 Sep 2018, Rugxulo wrote:
Date: Fri, 14 Sep 2018 11:01:39 -0500
From: Rugxulo
Reply-To: Technical discussion and questions for FreeDOS developers.
To: freedos-devel
Subject: Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
Hi,
On Fri, Sep 14, 2018, 8:49 AM Seth Simon wrote
Oops! Forgot to change the recipient address. ;-)
On Sat, Sep 15, 2018 at 4:36 PM Rugxulo wrote:
>
> Hi, Bart, (off-list)
Well, it's still on-topic, I just didn't want to pollute the thread
with such a silly suggestion. It's not really a bug report nor
(barely) worth worrying about.
Hi, Bart, (off-list)
I know this is a very minor issue, but I'm just trying to be helpful.
I know it's not much, so feel free to ignore completely, it won't hurt
my feelings.
On Mon, Sep 3, 2018 at 7:45 PM Bart Oldeman wrote:
>
> I now updated the prerelease to pre6
>
>
Hi,
On Fri, Sep 14, 2018, 8:49 AM Seth Simon wrote:
>
> In MS-DOS 6.22, neither "if exist ::\nul echo exist" nor "if exist Q:\nul
> echo exist" (where Q is a drive that doesn't exist) will cause anything to
> be echoed.
I know this is a common DOS idiom, but keep in mind that I don't recall
Hi Bart,
In MS-DOS 6.22, neither "if exist ::\nul echo exist" nor "if exist Q:\nul
echo exist" (where Q is a drive that doesn't exist) will cause anything to
be echoed. But in all 3 of commandg.com, commandt.com, and commandw.com,
both of those commands will echo "exist". But it's not a
Entschuldigung!
On Tue, Sep 11, 2018 at 8:12 AM Tom Ehlert wrote:
>
> > The GNUC version seems to mostly work,
I didn't quite have the time or energy to test TC or Watcom builds
yet. In fact, due to external circumstances, some tests
regressed/broke even with original (2006, TC) FreeCOM, which
> Hi, sorry for delay in testing this a bit,
> On Mon, Sep 3, 2018 at 7:45 PM Bart Oldeman wrote:
>>
>> thanks again everybody for the feedback. I now updated the prerelease to
>> pre6 with mostly bug fixes and one build system change
>>
>> I hope this is finally stable enough for me to remove
Hi, sorry for delay in testing this a bit,
On Mon, Sep 3, 2018 at 7:45 PM Bart Oldeman wrote:
>
> thanks again everybody for the feedback. I now updated the prerelease to
> pre6 with mostly bug fixes and one build system change
>
> I hope this is finally stable enough for me to remove the pre6
Hi Bart,
>> is there any reason why the source code version control system trashes
>> file modification dates?
> the underlying reason is to play well with "make" so that say if you
> check out a file as it was two years ago and then use "make", make
> will compile it because the timestamp of
Hi Tom,
> is there any reason why the source code version control system trashes
> file modification dates?
the underlying reason is to play well with "make" so that say if you
check out a file as it was two years ago and then use "make", make
will compile it because the timestamp of the file
Hi Bart,
is there any reason why the source code version control system trashes
file modification dates?
Tom
am 4. September 2018 um 02:45 schrieben Sie:
> Hi,
> thanks again everybody for the feedback. I now updated the prerelease to
> pre6 with mostly bug fixes and one build system change,
46 matches
Mail list logo
