Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 finalize 0.7 and upload it to iBiblio for us. > > does it include a fixed freecom? No because "fixed" doesn't exist (yet). It's safe to assume that Bart is busy elsewhere. But anyways, I uploaded what I had, just in case it helps with testing somehow. > does it run all tests? I'm not aware of any broken "tests" in this (0.7) release, with old (2006) FreeCOM, no. So it should work fine (or "better", even, since some external, third-party things regressed since 0.6). Not perfect but hopefully better than nothing. > > Just in case you're interested. (Maybe I should waited until tomorrow > > ... right, Tom? Right?? AM I RIGHT???) > > what am I supposed to do or say? Just laugh. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
> 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 >> Curl. >> I haven't rebuilt those, ugh, annoying.) > Nobody said anything, so I didn't worry about it. But I did (barely) > just do minor fixes and finalize 0.7 and upload it to iBiblio for us. does it include a fixed freecom? does it run all tests? > Just in case you're interested. (Maybe I should waited until tomorrow > ... right, Tom? Right?? AM I RIGHT???) what am I supposed to do or say? Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 > Curl. > I haven't rebuilt those, ugh, annoying.) Nobody said anything, so I didn't worry about it. But I did (barely) just do minor fixes and finalize 0.7 and upload it to iBiblio for us. Just in case you're interested. (Maybe I should waited until tomorrow ... right, Tom? Right?? AM I RIGHT???) * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/metados/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 beyond 64K (the libc for > ia16-elf-gcc started very bare bones in this respect!) that should be fine then. however IIRC MSC sbrk() would (try to) expand the allocated DOS memory to grow the stack; this would not work well with command XMS-SWAP. > 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 more. > One could easily swap heap and stack in ia16-elf-gcc though I think we > would just see different memory corruption, stack can then go corrupt > other data or even code. possibly a misunderstanding by me: if the stack and heap have clearly defined, separate areas, you are absolutely right. (it made debugging somewhat easier that REN destroyed always the same data, but that's a minor detail). I had understood 'heap grows up toward stack' as some sort of optimization so that the heap can grow at the cost of stack and vice versa. > (that still leaves Turbo C which also grows heap to stack.. and of > course protected mode OSes do it but with virtual memory protection virtual memory stack protection is really cool (at least in the MSVC implementation which happens to be the only one that I am knowledgeable in); all stack checking without any cost. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 more. Yes, I finally got around to implementing the _heaplen variable from Turbo C into gcc-ia16. :) I hope to put out a new release of the whole gcc-ia16 toolchain after I have run the regression tests once through. On the FreeCOM side, I find that the code to locate and patch _heaplen (utils/mkinfres.c, tools/ptchsize.c) will probably also need to be updated to handle the gcc-ia16 output. This turns out to be a bit trickier than I thought. Thank you! -- https://github.com/tkchia/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 libc for ia16-elf-gcc started very bare bones in this respect!) 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 more. One could easily swap heap and stack in ia16-elf-gcc though I think we would just see different memory corruption, stack can then go corrupt other data or even code. (that still leaves Turbo C which also grows heap to stack.. and of course protected mode OSes do it but with virtual memory protection they never get close to each other, and this is what can make small mode DOS debugging extra hard). Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 command.com is forbidden, as the amount to swap in/out is calculated once at init time, unless this code is also fixed. swapping in/out only part of the heap (and thereby destroying its content some of the time) isn't going to make anybody happy. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 BAD IDEA. (not
your idea, I know)
let me explain.
ignoring recursion for the moment, maximum stack use
can be statically evaluated
will not change unless you make major changes
you can request the required amount using some linker switch, and
rely that this amount will always be available; no stack checking
in production code necessary.
also: requesting stack (like calling a function) *must not fail*,
otherwise CRASH.
in contrast, malloc() may fail; virtually all malloc ocde runs like
char *p = malloc(some_amount);
if (p == NULL)
{ // fail decently, dont CRASH
printf("unable to allocate");
return FALSE;
}
now consider a heap that grows into the stack:
depending on the programs allocating history there may be
sometimes enough stack, sometimes not.
sometimes you see funny characters in your editor, sometimes the
linked list pointer gets overwritten.
this is just asking for
trouble, and extremely frustrating debugging sessions.
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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) but the heap which grows towards the stack. The default heap is very small though (6K), still it grows much further than OW's (with OW the stack is below the heap though but I debugged it a few times). Thanks for the information! I added some further debugging lines --- for temporary use --- to try to show how the heap top address (sbrk) changes over time, and to highlight to the user whenever there is a huge jump in the sbrk: https://gist.github.com/tkchia/c27c47e85550914e37ca85f82952f015 When I run the patched command.com with metados.img, the sbrk gets a huge jump (from 0x18d8 to 0x21e0) around the time of the exec( ) call on the command "xmssize.com 5 >NUL". I find this very strange (since I do not expect exec( ) to need to mess with the heap). There is another huge jump in the sbrk (0x21e0 -> 0x2dd0) around the cmdptr->func( ) of "dir /s/a-d/b a:\fetchbat.zip". It seems this is not merely a case of the heap becoming too fragmented and growing too fast --- though I am not sure yet what it actually is. Thank you! -- https://github.com/tkchia/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 the heap which grows towards the stack. The default heap is very small though (6K), still it grows much further than OW's (with OW the stack is below the heap though but I debugged it a few times). You can easily make it bigger in build.sh, with 8K metados boots. 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. Anyway, even with that and 8K, "tests oberon16" in metados still fails. With OW command.com "tests oberon16" finishes (although it reports "BEF - bad command or file name" in the beginning), but if I run it twice the second one fails with invalid opcodes (ie. memory corruption). I'll debug this some more to see if older freecoms had this issue too. Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 kernel. I'm still mostly preferring 2041 because of one regression. > should this not be fixed *before* the next freedos is released, with > known to be buggy software included? 1.3-RC1 is not even a month old. I'm almost surprised Jerome hasn't whipped out a new RC yet. Jim is extra busy. Even I'm very heavily distracted (not that I count for much, I admit). Bart is also always busy (I presume), so I don't blame him for taking his time. I had to replace the (old, failing) HDD in this main desktop, but everything's fine again (had Win7 reinstalled). I've downloaded but not tested 1.3-RC1 yet. 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 Curl. I haven't rebuilt those, ugh, annoying.) > correct licenses may matter for some, but most care more for correct > working software; in particular if the buggy software (kernel and > command) is the very heart of freedos. What licenses? You mean free/libre build tools or other things?? Nothing is perfect, so if we wait for it to become perfect, we'll be waiting forever. We just have to do our best, "good enough" (for now), and worry about the minor details later. (Anybody who complains can feel free to directly contribute, patches welcome, etc. We can't do literally everything.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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, especially when it comes to debugging the gcc-ia16 version. Also: (*) I recently (late Sep 2018) got GCC's stack protector functionality (-fstack-protector) working, and I find that I can build command.com with this option. (Using -fstack-protector-all instead makes the code section too big and fail to link.) (*) I have also been thinking of developing a small Electric Fence-like library for gcc-ia16 to detect stack overflow/heap overflow/null-dereference errors, by way of 386 debug registers (where they exist). I am not sure how useful such a library will be, though. Thank you! -- https://github.com/tkchia/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 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. Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 calls > fillFnam() together use at least 13 ~256-sized fixed sized filename > buffers, which is already 3.3K right there. > You can raise the stack for OW in shell/wlinker.bat to at least 6K, > maybe 8K is better to be more on the safe side. Or alternatively > redesign that code a bit to use less stack space. > Or also just compile without -s to enable stack checking and see what > that gives. I'll do some more tests tomorrow. 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 kernel. should this not be fixed *before* the next freedos is released, with known to be buggy software included? correct licenses may matter for some, but most care more for correct working software; in particular if the buggy software (kernel and command) is the very heart of freedos. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 enough.
if not exist unistd.c~ ren unistd.c *.c~
needs 4600 bytes (see below)
so far all retested
TESTS KE2041
TESTS JED
TESTS PICOC
work, but require at least 4600 byte stack
> Since Blair Campbell's LFN work in 2006 cmd_rename() which calls
> fillFnam() together use at least 13 ~256-sized fixed sized filename
> buffers, which is already 3.3K right there.
maybe finally found the reason nobody wants to use this code
fixing bugs is not sexy. leaving bugs as an exercise to the reader.
> You can raise the stack for OW in shell/wlinker.bat to at least 6K,
> maybe 8K is better to be more on the safe side.
so far found code that uses 4600 byte
I will take 8k as it doesn't matter much as everything is swapped out anyway.
> Or alternatively
> redesign that code a bit to use less stack space.
> Or also just compile without -s to enable stack checking and see what
> that gives. I'll do some more tests tomorrow.
I added the following to shell\command.c
int process_input(int xflag, char *commandline)
{
...
if(tracethisline)
--tracemode;
}
+{
+extern int stack_check(const char *commandline);
+
+stack_check(parsedline);
+}
}
while (!canexit || !exitflag);
and later
static void * stack_bottom, * stack_unused;
void stack_check_init()
{
char current_stack_location;
void **barrier;
//
place a barrier at the
//
bottom of the stack
// code
assumes 8 K right now
stack_bottom = _stack_location - 8*1024 + 50;
stack_unused= (char*)(_stack_location);
for (barrier = stack_bottom; barrier < stack_unused ; barrier++)
{
*barrier = barrier;
}
}
int stack_check(const char *commandline)
{
void **barrier;
for (barrier = stack_bottom; barrier < stack_unused; barrier++)
{
if (*barrier != barrier)
{
break;
}
}
if (barrier < stack_unused)
{
unsigned stack_left = (char*)barrier - (char*)stack_bottom;
if (stack_left < 5000)
{
printf("stack left %u after
<%.60s>\n",stack_left,commandline);
cgetchar();
}
stack_unused = barrier;
}
return 0;
}
int main(void)
{
/*
* * main function
*/
stack_check_init();
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 ~256-sized fixed sized filename buffers, which is already 3.3K right there. You can raise the stack for OW in shell/wlinker.bat to at least 6K, maybe 8K is better to be more on the safe side. Or alternatively redesign that code a bit to use less stack space. Or also just compile without -s to enable stack checking and see what that gives. I'll do some more tests tomorrow. Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 somewhere. I'll dig further... Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 *p)
{ struct CopySource *h;
char *q;
printf("copy %u: addsource %s\n", __LINE__, p);
assert(p);
q = strtok(p, "+");
assert(q && *q);
printf("copy %u: addsource %s\n", __LINE__, p);
this results in output
copy 500: addsource command.com
copy 506: addsource command
for some reason strtok("command.com", "+"); found a "+"
I verified that "command.com" is still "command.com", and "+" is still
"+".
where can I find the watcom clib source?
strtok() is used in many places; and might be the source of more
trouble.
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 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 https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 Thanks Robert, should had at two more cups of coffee this morning, I just saw the first and the last 3 digits and totally missed the important 2nd one...:-[ Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 +++ Home page: http://www.bttr-software.de/ DOS ain't dead: http://www.bttr-software.de/forum/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 82758 (without UPX) should this not be identical? One would expect so. But a two byte difference, and the bug in one version and not in the other, that's indeed strange but should be able to track this down with a binary compare and then check the code around that area where the difference occurs with a debugger. Could be as simple as missing a push/pop instruction in a (RTL?) routine due to premature optimization and hence a clobbered register... Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 double check later today. Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 identical? Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 failing to download Tar (via FTP), for some unknown "new" > reason. (Don't you just love that? Ugh!) Not entirely sure, but apparently that specific FTP mirror is now seemingly "HTTPS only" for downloads. So that makes Wget (386+) even more mandatory, which is somewhat unfortunate. I may have to switch to a different FTP mirror, assuming even that would be reliable (for what random small pieces I sometimes rely upon). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
> 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. if they succeed, or fail (because a download fails, the archive no longer exists, or other reason), all 3 new freecoms and the old one from 2006 should (in first approximation) behave identical. I was looking for differences, and I found some. it would have been cool to have TESTS ALL which would run all tests (and takes 24 hours to finish), and list successes/fails. I very much prefer to have my computer work 24 hours, rather then my interacting with it every 20 minutes - for 24 hours. > Most of > what I ran did seem to work in latest prerelease (GNUC build). Indeed > there are still obscure bugs. as you didn't document the obscure bugs, I had to redo your work :-< Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 2006 TC build, "tests /t jed" succeeds for me in 3 min. 58 sec. (so, roughly, 4 minutes). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 PM 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 > > anyway, I downloaded this, and replaced the 32-bit system\unzip.exe > with 16-bit unzip.exe from > ftp://ftp.info-zip.org/pub/infozip/msdos/unz600x3.exe > which makes everything behave *much* faster under VirtualBox. This ancient Core i5 (Nehalem Westmere) from 2011 has VT-X. I read somewhere that most machines (since 2015?) have it now, too. It helps a lot in speed. Most tests are simple and fast enough either way, but some are admittedly too slow (e.g. p7zip). > then I created 3 instances of this machine, replacing command.com > by commandT/W/G.com in https://github.com/FDOS/freecom/releases/tag/com084pre6 > > everything else identical. > tested on Windows-32, VirtualBox, 256 MB machine size. > > the idea is that they should behave identical. They don't. > * > restart machine. BTW, you can use Host (Right Ctrl, aka StrG) + R to reboot VBox. I also included a simple reboot.com (mostly useful for QEMU), but I don't recall it working correctly under VBox (at the time). >TESTS JWASMDJ > > after 1572 seconds, everything seems to have worked. > ok it worked, but slow as molasses. Newer DJGPP (GCC) is even bigger and slower, believe it or not. But some code can't run on ancient versions. (Even NASM 2.x requires C99 since 2005, hence you probably need GCC 3.2.3 or newer, IIRC.) This one succeeds for me in 2 min. 5 secs. (And it successfully rebuilds Xgrep.) > * > restart machine. >TESTS CTAGS > all 3 fail quickly with a ctags58.zip problem. might be a unzip.exe bug. IIRC, this is trying to download from SF.net, so you need the "new" Wget runnable first. It succeeds in 21 secs. for me. > * > restart machine. >TESTS PICOC This one succeeds in 52 secs. for me. > * > restart machine. >TESTS P7ZIP > > aborted on all 3 machines after waiting forever. identical bug, or no freecom > bug at all. IIRC, it needs 512 MB of RAM (or, more specifically, 256 MB free on the RAM disk). Hmmm, I should've documented that in the .BAT. (BTW, "tests p7zip edit" is convenient.) Also it downloads source from SF.net, so you need "new" Wget again. Also slow as molasses. I think it once took me like five hours (!) without VT-X. (I think it was 11 hours until I avoided LFNs entirely!) But with latest VBox and VT-X enabled (Nehalem Westmere, which is more DOS-friendly), it just now "only" took me 13 minutes. > * > 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 failing to download Tar (via FTP), for some unknown "new" reason. (Don't you just love that? Ugh!) Trying "tests /t nasmwat djtar" succeeds for me in 47 secs (new Wget) or 1 min. 2 secs. (FTP). I was somewhat obsessed with having a modern NASM build (or two) that ran in all environments. I absolutely didn't want us having to rely on an old, 16-bit build, 0.98.39 only, that nobody could ever upgrade. And mixing DJGPP or OpenWatcom binaries together usually won't work, has compatibility issues (esp. with Wmake, but WmakeR is probably okay). I intend to add another .BAT for latest NASM 2.13.03 (using DJGPP) one of these days, but I've been too preoccupied. > * > restart machine. > TEST KE2041 > > freecomW fails with 'bad command or filename - "patch.exe" You have to be careful here. The DJGPP people often delete old versions and put new ones in its place. So downloads will break, unfortunately. But it's a simple edit of a .BAT to fix that. Still unfortunate. (Maybe not the exact problem here but still worrisome.) BTW, this succeeds in 1 min. 21 secs. > * > summary: > > both watcom and gnu builds have at least one bug left. We're getting there. Yes, it'd be great (huge understatement) to have GCC IA-16 able to build the kernel and shell (without regressions). Bart and you (et al.) have done great work. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 whether I was
testing the public release or a private, unfinished one. So, just to
be obvious, I uploaded it for you.
> are we all required to note all your more or less old emails?
Since you were the one expressing interest, then yes, I expected you
to remember and download the new version from DropBox. The fact that
you forgot or didn't care is fine, but it's not my fault. Like I said,
I don't expect you to worry much with this. But there indeed have been
regressions since the ancient 2006 TC build, which is why I still
stick to using that old one by default.
But yes, it's very spaghetti .BAT scripting, so I don't blame you for
being confused. It wasn't well-polished, and it wasn't really meant to
be super user-friendly at all. "Tests" are just there for fun
diagnostics, not necessarily for real work.
> anyway, I downloaded this, and replaced the 32-bit system\unzip.exe
> with 16-bit unzip.exe from
> ftp://ftp.info-zip.org/pub/infozip/msdos/unz600x3.exe
> which makes everything behave much better under VirtualBox.
Presumably QEMU (and VBox, which is derived from it) are moreso
optimized for Linux than DOS. And since Linux is always pmode, that
part is probably super slow (since DOS switches back and forth). I
don't know the details, but that's my blind guess.
But I had to use 32-bit Unzip for LFN support, which was needed by
some things (e.g. "tests turbopas"). So "maybe" you can recompile
Unzip16 with _WATCOM_LFN_ or whatever (I forget), but IIRC, that only
halfway worked since they (at that time) never finalized support for
that feature (yet).
> then I created 3 instances of this machine, replacing command.com
> by commandT/W/G.com in https://github.com/FDOS/freecom/releases/tag/com084pre6
>
> everything else identical.
> tested on Windows-32, VirtualBox, 256 MB machine size.
Which VBox? 5.2.20 is latest. (Not that it should matter, but
sometimes it does.)
Also, 512 MB is a better size (for some very few, maybe two??, tests),
but overall I "normally" only use 128 MB.
> the idea is that they should behave identical. They don't.
>
> *
>
> here's a watcom bug:
>
> start the machine.
> run
>TESTS JED
>
> this should download a lot of stuff, build JED (whatever that is), and keep
> the
> machine busy for 10 minutes.
JED is a text editor (loosely, Emacs clone).
> FreeCOM-watcom will stop fairly quickly with
>
> unzip: cannot find any matches for wildcard specification fil4*.zip
>
> and short after abort the build.
I'd have to run that test again (which is not top priority at the
moment), but that's clearly DJGPP FileUtils. (Back before File- +
Text- + Shell- were merged into CoreUtils. Yeah, DJGPP is somewhat
antiquated.)
> strange side effect: after this test, the command
>
>a:>copy commandW.com system\command.com
> results in
>the COPY destination must not contain plus ('+') characters.
>
> this might be easier to locate
I really wasn't expecting you to directly run all "tests". Most of
what I ran did seem to work in latest prerelease (GNUC build). Indeed
there are still obscure bugs.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
> 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 system\unzip.exe
with 16-bit unzip.exe from ftp://ftp.info-zip.org/pub/infozip/msdos/unz600x3.exe
which makes everything behave *much* faster under VirtualBox.
then I created 3 instances of this machine, replacing command.com
by commandT/W/G.com in https://github.com/FDOS/freecom/releases/tag/com084pre6
everything else identical.
tested on Windows-32, VirtualBox, 256 MB machine size.
the idea is that they should behave identical. They don't.
*
here's a watcom bug:
start the machine.
run
TESTS JED
this should download a lot of stuff, build JED (whatever that is), and keep the
machine busy for 10 minutes.
FreeCOM-watcom will stop fairly quickly with
unzip: cannot find any matches for wildcard specification fil4*.zip
and short after abort the build.
strange side effect: after this test, the command
a:>copy commandW.com system\command.com
results in
the COPY destination must not contain plus ('+') characters.
this might be easier to locate
freecom-T and -G (seem to) behave as expected.
*
just to save everybody else some time:
restart machine.
TESTS AWK(seems to) work
*
restart machine.
TESTS OBERON16 seems to work, but
nearly at the end (after bef93om.mod) , commandG results in 'out of memory
error'
not good.
*
restart machine.
TESTS JWASMDJ
after 1572 seconds, everything seems to have worked.
ok it worked, but slow as molasses.
*
restart machine.
TESTS CTAGS
all 3 fail quickly with a ctags58.zip problem. might be a unzip.exe bug.
*
restart machine.
TESTS PICOC
...patching...
after a short time, the WATCOM machine reports several times
the COPY destination must not contain plus ('+') characters.
the COPY destination must not contain plus ('+') characters.
the COPY destination must not contain plus ('+') characters.
later, time.c fails to compile.
bad.
commandT and -G build success
*
restart machine.
TESTS P7ZIP
aborted on all 3 machines after waiting forever. identical bug, or no freecom
bug at all.
*
restart machine.
TESTS SHSURDRV
success.
*
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.
*
restart machine.
TEST KE2041
freecomW fails with 'bad command or filename - "patch.exe"
freecom-T and -G build kernel.sys ok.
*
summary:
both watcom and gnu builds have at least one bug left.
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
> 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 system\unzip.exe
with 16-bit unzip.exe from ftp://ftp.info-zip.org/pub/infozip/msdos/unz600x3.exe
which makes everything behave much better under VirtualBox.
then I created 3 instances of this machine, replacing command.com
by commandT/W/G.com in https://github.com/FDOS/freecom/releases/tag/com084pre6
everything else identical.
tested on Windows-32, VirtualBox, 256 MB machine size.
the idea is that they should behave identical. They don't.
*
here's a watcom bug:
start the machine.
run
TESTS JED
this should download a lot of stuff, build JED (whatever that is), and keep the
machine busy for 10 minutes.
FreeCOM-watcom will stop fairly quickly with
unzip: cannot find any matches for wildcard specification fil4*.zip
and short after abort the build.
strange side effect: after this test, the command
a:>copy commandW.com system\command.com
results in
the COPY destination must not contain plus ('+') characters.
this might be easier to locate
freecom-T and -G (seem to) behave as expected.
*
just to save everybody else some time:
restart machine.
TESTS AWK(seems to) work
restart machine.
TESTS OBERON16 seems to work, but
nearly at the end (after bef93om.mod) , commandG results in 'out of memory
error'
not good.
*
restart machine.
TESTS JWASMDJ
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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. > often this is not needed; bugs in one version of FreeCOM will most > likely also occur in the other versions (compilers should take care of > this). fixing this one bug in GNU freecom most likely also fixes the > watcom bug. > > so once you locate an error in one FreeCOMxyz, please write down > the failing batch, and circumstances how to reproduce. > > once bugs are reproducible the fix is usually easy. newwget.bat is a dependency of some "tests" (e.g. "tests c89") because the older Wget won't work on Github anymore. Trying it again, it does seem to work with TurboC and Watcom builds ... but not the GNUC / GCC one! > > Did you want a list of "successful" tests?? Or just the failures, > > right? > just the failures. If you type "tests", it should show you a list of various tests you can run. But it's brittle, and some things have regressed, so some things don't work (or aren't obvious). It wasn't meant to be super obvious or useful (necessarily), just some random stuff I tried. The tests were moreso for making sure the pieces all worked together correctly, not necessarily for installing and using the programs "as is". (Also, it was to try to pretend to be halfway reproducible for some things and test some compilers.) > > You have the same files that I do (now), if you think it makes > > much of a difference (since 0.6). > > but you refuse to tell te failing tests. any reason for this? newwget.bat was (part of) the failing test. Actually, that's a stub, but you know what I mean. The other errors I was getting were irrelevant (spurious, aka fake), so it still worked but outputted some weird text to the screen. > >> > However, trying to run NEWWGET.BAT seems to hang > >> > forever. > >> what f**king NEWWGET.BAT? not part of my copy of this world famous > >> METADOS. > >> mind sharing this with us so we might try to reproduce this? BTW, part of the problem is trying to use both FTP and Wget. So don't be surprised when it's mixing both. Somewhat confusing but can't be easily helped. I wish everything was available from FTP, but it's not. Anyways, at startup, you can "set QUIET=" (to unset) for some more verbose output. Technically, you can do that at any time for FTP, but Wget uses its own wgetrc file, so that's why you have to do it at startup (or else edit the text file manually). So "maybe" that will be more verbose and helpful for you?? > > Aug. 21 email (in last thread about previous prerelease) had a link to > > my DropBox, which I explicitly mentioned here. Inside > > "network/stubs.zip" is indeed found "newwget.bat" (which is unpacked > > to "%RAMDRIVE%:\utils" at bootup). Are you still using only (old) 0.6? > > It was because of your alleged confusion (0.6 or newer?) that I > > uploaded this for you. > in the age of internet it helps to post links to the uploaded stuff. > > remember: this is a mailing list. it's content should still make sense > when someone else reads this 2 years later. Here's the DropBox link (again), in case it wasn't obvious: * https://www.dropbox.com/s/6whjgmb9xhdgw29/metados-0.7.zip?dl=0 BTW, "2 years later" is somewhat unfairly optimistic. Back in November (almost a year ago), MetaDOS 0.6 relied exclusively on the old (2008) DJGPP build of Wget 1.11 already mirrored on iBiblio for years. And it worked fine, but then Github and SF.net changed protocols or whatever, so now it won't work. So even things that do work will regress or break due to unforeseen external circumstances. It could be anything (QEMU bug or SeaBIOS bug or abandoned Windows port). I guess nothing lasts forever. (Heck, I don't use Windows 10 32-bit, but Andris from DJGPP said even there NTVDM has been broken for months. I don't know the details or if they fixed it, but last I heard it was still broken. See what I mean? Everything breaks without warning.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 will most likely also occur in the other versions (compilers should take care of this). fixing this one bug in GNU freecom most likely also fixes the watcom bug. so once you locate an error in one FreeCOMxyz, please write down the failing batch, and circumstances how to reproduce. once bugs are reproducible the fix is usually easy. > Did you want a list of "successful" tests?? Or just the failures, > right? just the failures. > You have the same files that I do (now), if you think it makes > much of a difference (since 0.6). but you refuse to tell te failing tests. any reason for this? >> > However, trying to run NEWWGET.BAT seems to hang >> > forever. >> what f**king NEWWGET.BAT? not part of my copy of this world famous >> METADOS. >> mind sharing this with us so we might try to reproduce this? > Aug. 21 email (in last thread about previous prerelease) had a link to > my DropBox, which I explicitly mentioned here. Inside > "network/stubs.zip" is indeed found "newwget.bat" (which is unpacked > to "%RAMDRIVE%:\utils" at bootup). Are you still using only (old) 0.6? > It was because of your alleged confusion (0.6 or newer?) that I > uploaded this for you. in the age of internet it helps to post links to the uploaded stuff. remember: this is a mailing list. it's content should still make sense when someone else reads this 2 years later. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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: 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 this kludge working with XP's CMD. So it's a bit brittle (like all such similar tricks). But But in all 3 of commandg.com, commandt.com, and commandw.com, both of those commands will echo "exist". But it's not a regression because 0.84-pre2 does the same thing (the FreeCom tests were done under FreeDOS, not MS-DOS). Ah, then this is that same bug/regression in kernel 2042 (only). Try older 2041, it should work fine there. (I'm pretty sure Jeremy already knows about it.) I meant that I did the former test on an actual, real MS-DOS 6.22 boot diskette, not XP. But indeed, as you said, the bug is in the kernel- I can confirm that the 0.84-pre6 shell works as expected under the 2041 kernel. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 > > https://github.com/FDOS/freecom/releases/tag/com084pre6 Apparently you still carry around some binaries in the source archive (which is "bad"). I vaguely remember them being included in the old sources too. Not sure why (beyond the obvious fact that someone wanted them for changing screen size), but it doesn't appear that they have sources included. (Admittedly, they are very small, easy to disassemble.) EDIT: I think MODE can already support these modes, and of course we have similar tools mirrored on iBiblio for us. So maybe you'll just remove these entirely. That was not my intention to suggest that, but you may find it truly redundant and irrelevant, who knows. Then again, maybe you put them there on purpose, thus it wasn't just a small oversight! Archive: e:/temp/freedos/freecom/freecom-com084pre6.zip 274b4a9b74e2371a384e7041dd026dd16dec34dc Length DateTimeName - -- - 8 09/02/2018 20:08 freecom-com084pre6/bin/28.com 8 09/02/2018 20:08 freecom-com084pre6/bin/50.com - --- 16 2 files So here's my solution: .BAT debug scripts! Plain text (totally legible), small, easy to run, easy to reassemble. *28.bat*** @echo off if not exist %0 %0.bat if not exist %0 goto end debug < %0 if not exist 28.com goto end echo. dir 28.com | find /i "com" echo. goto end n 28.com rcx 8 a 100 mov ax, xor bl,bl int 10 ret w Q Q :end ** *50.bat*** @echo off if not exist %0 %0.bat if not exist %0 goto end debug < %0 if not exist 50.com goto end echo. dir 50.com | find /i "com" echo. goto end n 50.com rcx 8 a 100 mov ax,1112 xor bl,bl int 10 ret w Q Q :end ** These .BATs are too trivial to license, but feel free to consider them whatever you want (p.d. or GPLv2+ or whatever). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 this kludge working with XP's CMD. So it's a bit brittle (like all such similar tricks). But But in all 3 of commandg.com, commandt.com, and commandw.com, both of those > commands will echo "exist". But it's not a regression because 0.84-pre2 > does the same thing (the FreeCom tests were done under FreeDOS, not MS-DOS). > Ah, then this is that same bug/regression in kernel 2042 (only). Try older 2041, it should work fine there. (I'm pretty sure Jeremy already knows about it.) > ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 regression because 0.84-pre2 does the same thing (the FreeCom tests were done under FreeDOS, not MS-DOS). - Seth ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 I'm normally using by default. So that's four shells and (I don't know? 20+?) many "tests" that I have to re-run. Quite a few tests seemed to work okay now with the GNUC build, though, which is very promising and good news. > > at least in several of my tests. It's still reporting spurious "Out of > > memory error" and > > "Invalid switch - /d" (for unknown reasons), but some common tests > > seem to succeed now. Not sure exactly why those errors, but "spurious" (false or fake) means I'm just ignoring them, for now. > > (This is on 0.7-pre snapshot that I linked in my > > DropBox, if that makes a difference, run under 64-bit QEMU 3.0.0 atop > > Win7 64-bit.) > > well as usual: no mentioning of WHAT F**KING TEST YOU DID > can't be so difficult, right ? I ran over a dozen tests. They all test different pieces. It's not that simple or one dimensional. Part of that is intentional. Did you want a list of "successful" tests?? Or just the failures, right? You have the same files that I do (now), if you think it makes much of a difference (since 0.6). > > However, trying to run NEWWGET.BAT seems to hang > > forever. > what f**king NEWWGET.BAT? not part of my copy of this world famous > METADOS. > mind sharing this with us so we might try to reproduce this? Aug. 21 email (in last thread about previous prerelease) had a link to my DropBox, which I explicitly mentioned here. Inside "network/stubs.zip" is indeed found "newwget.bat" (which is unpacked to "%RAMDRIVE%:\utils" at bootup). Are you still using only (old) 0.6? It was because of your alleged confusion (0.6 or newer?) that I uploaded this for you. Yes, I've now tested it (here under antiX Linux via live USB), and it can indeed be downloaded successfully. But keep in mind that I'm not expecting nor demanding any serious debugging, just casually mentioning what I'm seeing. > > But using the old (2008) Wget (e.g. "tests oberon") seems to > > work fine. (Of course, the problem is that some sites don't work with > > that old Wget anymore.) > > > I know that's not saying much, but it's something ... right? > your bug reporting could be worse, but it's not easy. I'm not sure if M.K.'s site is down (or was yesterday), so it could've been that. It's a shame that I might even have to (again) run the (normally "successful") test under original (2006, TC) FreeCOM just to make sure it still works as originally intended. Some things are outside of my control. (But it's very tedious to rebuild and mirror only free/libre stuff with nobody to help. Please keep in mind that I'm not normally trying to make things harder for myself or others. I'm not normally trying to be too clever or baroque.) So I didn't have time to fully isolate the problem on my end to make absolutely sure it's a bug or regression in newer FreeCOM prerelease. I just wanted to show that I did (briefly) try it out. More testing from me will come later, but (sadly) my time and energy is not infinite. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
> 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 and >> release this as 0.84. >> >> Happy testing! > I haven't tested literally everything, but ... > The GNUC version seems to mostly work, at least in several of my > tests. It's still reporting spurious "Out of memory error" and > "Invalid switch - /d" (for unknown reasons), but some common tests > seem to succeed now. (This is on 0.7-pre snapshot that I linked in my > DropBox, if that makes a difference, run under 64-bit QEMU 3.0.0 atop > Win7 64-bit.) well as usual: no mentioning of WHAT FUCKING TEST YOU DID can't be so difficult, right ? > However, trying to run NEWWGET.BAT seems to hang > forever. what fucking NEWWGET.BAT? not part of my copy of this world famous METADOS. mind sharing this with us so we might try to reproduce this? > But using the old (2008) Wget (e.g. "tests oberon") seems to > work fine. (Of course, the problem is that some sites don't work with > that old Wget anymore.) > I know that's not saying much, but it's something ... right? your bug reporting could be worse, but it's not easy. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 and > release this as 0.84. > > Happy testing! I haven't tested literally everything, but ... The GNUC version seems to mostly work, at least in several of my tests. It's still reporting spurious "Out of memory error" and "Invalid switch - /d" (for unknown reasons), but some common tests seem to succeed now. (This is on 0.7-pre snapshot that I linked in my DropBox, if that makes a difference, run under 64-bit QEMU 3.0.0 atop Win7 64-bit.) However, trying to run NEWWGET.BAT seems to hang forever. But using the old (2008) Wget (e.g. "tests oberon") seems to work fine. (Of course, the problem is that some sites don't work with that old Wget anymore.) I know that's not saying much, but it's something ... right? ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 the file will be the current > date which is newer than the timestamp of the object file that you > still kept around. > https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F 1st, thanks for the explanation. 2nd, while i understand the motivation, I disagree with the 'solution', as file modification times brivide useful information when the file was last worked on. Git/subversion/... are not the only ways to look at the world. actually, when distributing source code in .ZIP files, all information of 'when was this last worked on' is lost (forever). 3rd, after thinking a while about it, here is how I would solve this problem. when extracting a file, store the 'last modification' time as is in the archive, but set 'file creation' time to 'NOW'. make xyzmake look at the younger of (file creation, last modified) time. xyzmake should be open source, anyway... this should avoid the cost of rebuilding the entire kernel, but leave modification time intact. Tom -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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 will be the current date which is newer than the timestamp of the object file that you still kept around. https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F For github those source code zipfiles and tarballs are automatically generated from a tag, I did not upload them myself. It is possible though somehow to convince it to use last-modification time == last time that file was really changed by using a hook. I can look into that. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
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, most importantly: > * Enable reporting of directory sizes up to 2TB (with Tom Ehlert) > * Enable cross-compilation from 64-bit Windows using Open Watcom > * Fix swapping of strings to XMS for GCC and OW versions (with TK Chia) > * Fix carry flag handling on input to DOS memory allocation functions > for GCC and OW (with TK Chia) > * Fix compilation errors with LFN disabled > * GCC inline assembly fixes (TK Chia) > * shift: use correct context, Fixes SF Bug #155 (Wolfram Sang) > * Fix buffer overflow with alias expansion, introduced in 0.84-pre3. > https://github.com/FDOS/freecom/releases/tag/com084pre6 > I hope this is finally stable enough for me to remove the pre6 and > release this as 0.84. > Happy testing! > Bart > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
