Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease

[Matej Horvat]

On Fri, 09 Feb 2018 14:47:58 +0100, Bart Oldeman   
wrote:



Hi Matej,

can you post your exact config.sys and which kernel.sys you are using?


It's a modified version of the default one from FreeDOS 1.1:

!DOS=HIGH,UMB
!DOSDATA=UMB
!LASTDRIVEHIGH=Z
!FILESHIGH=40
!MENUCOLOR=7,0
!IDLEHALT=-1

; (MENU commands skipped)

; Default configuration
COUNTRY=038
DEVICE=\DOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST FASTBOOT
DEVICEHIGH=\DOS\BIN\SRDXMS.SYS
SHELLHIGH=\COMMANDW.COM \DOS\BIN /E:1024 /P=\FDAUTO.BAT


however, I get 45 instead of 48 buffers in HMA, so the kernel is
likely different (the FD 1.2 kernel I got was 2042, Watcom, FAT32, May
11 2016).


Yes, I compiled it myself in 2015. It says it's 2042, but I don't know  
what has changed since then.


But even if you can't fix this, it's no problem for me to just work around  
it in FDAUTO.BAT.


--
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-pre3 prerelease

[Matej Horvat]

On Sun, 04 Feb 2018 22:40:25 +0100, Eric Auer  wrote:



Hi Matej,


1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and
DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel
prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then
right after that I see "Not enough memory" ...


Are you sure that this does not happen with older FreeCOM?


Yes.


I think this is still an improvement compared to the previous version
(if compiled with OW), but the Turbo C++ version does not have any of
these problems.


Please explain :-)


What I meant is that 0.84-pre2 was even more unstable when compiled with  
OW (I remember getting "MCB chain is corrupt" errors when using LOADHIGH).  
0.84-pre3 is better, but OW support is still lagging behind Turbo C++ in  
any case.


--
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-pre3 prerelease

[Rugxulo]

Hi,

On Sat, Feb 3, 2018 at 4:44 AM, Bart Oldeman  wrote:
>
> as some of you know I spent some time fixing various bugs in FreeCOM.
>
> So for testing I uploaded a new prerelease on github:
> https://github.com/bartoldeman/freecom/releases/tag/com084pre3
>
> There are three non-UPXed xms-swap command.com's in the binary zip,
> one compiled with Turbo C++ 1.01 (as the older version were), one
> cross-compiled with OW 1.9 and one cross-compiled with ia16-elf-gcc.
> Please test and let me know how stable they are in your testing.

Unfortunately, under QEMU, it seems none of these work correctly (in
my latest MetaDOS image).
Maybe it's some side effect of something else or some quirk in my
secondary configs somewhere.

GCC build bombs out with "Invalid Opcode".
OpenWatcom gives some "Out of memory" errors and hangs before I can
even do anything else.
TurboC++ similarly hangs at end of bootup.

I'm willing to try again eventually (of course), but this kind of
thing is not exactly obvious on what's going wrong.

--
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-pre3 prerelease

[Tom Ehlert]

Hi Bart,


> that syntax is unfortunately incompatible with FreeCOM itself and
> COMMAND.COM too.
I always forget about FreeCOM itself :<<

> How about this:

my solution would be


   set AMP=&
   if "%AMP%" == "" set AMP=^^^&

   echo %STR% %AMP%>> %FILE%

tested on windows only.

> as for stack growing down to heap I think the compiler's stack
> checking / malloc returning NULL should take care of that..

in theory yes.
in praxis only if stack checking is enabled...

thanks for taking care of /lfn (and other bugs)

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-pre3 prerelease

[Bart Oldeman]

Hi Matej,

can you post your exact config.sys and which kernel.sys you are using?
I cannot reproduce your issue with a plain FD 1.2 installation in QEMU
with this:
DOS=UMB,HIGH
DEVICE=C:\FDOS\BIN\JEMMEX.EXE
SHELLHIGH=C:\COMMANDW.COM
DEVICEHIGH=c:\srdxms.sys

where srdxms.sys comes from srdsk209c.zip.

however, I get 45 instead of 48 buffers in HMA, so the kernel is
likely different (the FD 1.2 kernel I got was 2042, Watcom, FAT32, May
11 2016).

I have fixed the issue with dir/lfn in the SVN source code now.

Bart








On 4 February 2018 at 11:38, Matej Horvat  wrote:
> I found these bugs in the OW version so far:
>
> 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and
> DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel
> prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right
> after that I see "Not enough memory" (not sure what prints that), and
> FreeCOM prints "The shell is about to be terminated, though, this is
> forbidden", etc., and hangs. Loading the same driver with DEVLOAD from
> FDAUTO.BAT works fine.
>
> 2. Sometimes, after loading some TSRs from FDAUTO.BAT (e.g. Bret Johnson's
> CLOCK), FreeCOM hangs, though I can't reliably reproduce that and loading
> the same TSRs manually works fine.
>
> 3. With the DIRCMD environment variable set to "/OGN/LFN" (possibly with
> other options), FreeCOM prints "Out of memory" instead of the expected long
> file names - but "/LFN" by itself works fine.
>
> I think this is still an improvement compared to the previous version (if
> compiled with OW), but the Turbo C++ version does not have any of these
> problems.
>
>
> --
> 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

--
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-pre3 prerelease

[Bart Oldeman]

Hallo Herr Tom Ehlert,

that syntax is unfortunately incompatible with FreeCOM itself and
COMMAND.COM too. How about this:
===

@echo off
set FILE=%1
set STR=+%2
rem read-only environment variable in cmd.exe (ignored there)
set CmdExtVersion=

:loop
shift
if "%2" == "" goto end
set STR=%STR% +%2
goto loop
:end

if "%CmdExtVersion%" == "" goto commandcom

rem in cmd.exe CmdExtVersion is set to either 1 or 2.
echo %STR% ^&>> %FILE%

goto theend

:commandcom
set STR=%STR% &

echo %STR%>> %FILE%

:theend


==
as for stack growing down to heap I think the compiler's stack
checking / malloc returning NULL should take care of that..

Bart


On 5 February 2018 at 10:47, Tom Ehlert  wrote:
> Hallo Herr Bart Oldeman,
>
> am 5. Februar 2018 um 11:06 schrieben Sie:
>
>> Hi Matej,
>
>> thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN.
>> It doesn't happen with the GCC compiled version either. I'll need to
>> debug this a bit.
>> OW has heap after stack unlike the other compilers, which have stack
>> after heap. Stack after heap allows a bit of flexibility as the two
>> grow to each other, so perhaps it's just that the heap is too small.
> if it's trashing the stack, this should be detected somehow, and
> printing some diagnostic message.
>
>
>> I'll let you know.
>
> for TCPP and Windows, please replace in ECHOLIB.BAT
>
>...
>set STR=%STR% &
>
>echo %STR%>> %FILE%
> by
>
>echo %STR% ^&>> %FILE%
>
>
> as a standalone '&' has special meaning for Windows CMD and gets eaten
>
> otherwise TCPP builds out of the box (something that wasn't possible
> for ~10 years). compliments.
>
> 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

--
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-pre3 prerelease

[Bret Johnson]

Tom: You are correct in that it happens with an INSTALL= line in CONFIG.SYS, 
though I never heard there was a known patch for it.  I don't use FreeDOS on a 
regular basis, so am not sure of the current state of this issue in the 
official releases.  In my case, it wasn't with RAMDISK.EXE that I noticed it, 
but rather one of my TSR's that needs access to the top part of conventional 
memory while installing.  The problem being discussed here may or may not be 
related at all, or may be related only indirectly.

Warning: Don't Use Probiotics Before You See This
gundrymd.com
http://thirdpartyoffers.juno.com/TGL3141/5a7b66fac741966fa05a0st01vuc--
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-pre3 prerelease

[Bret Johnson]

I'm not 100% sure, but this could be (at least indirectly) related to the issue 
I discovered several years ago, where FreeCOM uses memory "illegally" while 
installing (processing CONFIG.SYS and/or AUTOEXEC.BAT).  That is, FreeCOM uses 
a lot of memory that's at the top of conventional memory (just below the 640k 
point), but doesn't actually allocate (and thereby "protect") the memory with a 
Memory Control Block (MCB).  As a result, any program that actually tries to 
use that memory will crash the system since it doesn't know that FreeCOM is 
already using it. In my case, I was requesting an MCB at the top of 
conventional memory, and the kernel issued it to me even though it shouldn't 
have because the memory was already being used (by the kernel). Again, I don't 
know if this related to the particular problem Matej is having, but it seems 
like it could be.
-- Original Message --
From: Bart Oldeman <bartolde...@gmail.com>
To: "Technical discussion and questions for FreeDOS developers." 
<freedos-devel@lists.sourceforge.net>
Subject: Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Date: Mon, 5 Feb 2018 11:06:06 +0100

Hi Matej,

thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN.
It doesn't happen with the GCC compiled version either. I'll need to
debug this a bit.
OW has heap after stack unlike the other compilers, which have stack
after heap. Stack after heap allows a bit of flexibility as the two
grow to each other, so perhaps it's just that the heap is too small.
I'll let you know.

Bart

On 4 February 2018 at 17:38, Matej Horvat <matej.hor...@guest.arnes.si> wrote:
> I found these bugs in the OW version so far:
>
> 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and
> DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel
> prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right
> after that I see "Not enough memory" (not sure what prints that), and
> FreeCOM prints "The shell is about to be terminated, though, this is
> forbidden", etc., and hangs. Loading the same driver with DEVLOAD from
> FDAUTO.BAT works fine.
>
> 2. Sometimes, after loading some TSRs from FDAUTO.BAT (e.g. Bret Johnson's
> CLOCK), FreeCOM hangs, though I can't reliably reproduce that and loading
> the same TSRs manually works fine.
>
> 3. With the DIRCMD environment variable set to "/OGN/LFN" (possibly with
> other options), FreeCOM prints "Out of memory" instead of the expected long
> file names - but "/LFN" by itself works fine.
>
> I think this is still an improvement compared to the previous version (if
> compiled with OW), but the Turbo C++ version does not have any of these
> problems.
>
>
> --
> 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

--
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

The Unusual Link Between Alzheimer's and Coconut Oil (Watch)
Memory Repair Protocol
http://thirdpartyoffers.juno.com/TGL3141/5a7a161e77d43161e6b53st01vuc--
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-pre3 prerelease

[Tom Ehlert]

Hallo Herr Bart Oldeman,

am 5. Februar 2018 um 11:06 schrieben Sie:

> Hi Matej,

> thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN.
> It doesn't happen with the GCC compiled version either. I'll need to
> debug this a bit.
> OW has heap after stack unlike the other compilers, which have stack
> after heap. Stack after heap allows a bit of flexibility as the two
> grow to each other, so perhaps it's just that the heap is too small.
if it's trashing the stack, this should be detected somehow, and
printing some diagnostic message.


> I'll let you know.

for TCPP and Windows, please replace in ECHOLIB.BAT

   ...
   set STR=%STR% &

   echo %STR%>> %FILE%
by

   echo %STR% ^&>> %FILE%


as a standalone '&' has special meaning for Windows CMD and gets eaten

otherwise TCPP builds out of the box (something that wasn't possible
for ~10 years). compliments.

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-pre3 prerelease

[Bart Oldeman]

Hi Matej,

thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN.
It doesn't happen with the GCC compiled version either. I'll need to
debug this a bit.
OW has heap after stack unlike the other compilers, which have stack
after heap. Stack after heap allows a bit of flexibility as the two
grow to each other, so perhaps it's just that the heap is too small.
I'll let you know.

Bart

On 4 February 2018 at 17:38, Matej Horvat  wrote:
> I found these bugs in the OW version so far:
>
> 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and
> DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel
> prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right
> after that I see "Not enough memory" (not sure what prints that), and
> FreeCOM prints "The shell is about to be terminated, though, this is
> forbidden", etc., and hangs. Loading the same driver with DEVLOAD from
> FDAUTO.BAT works fine.
>
> 2. Sometimes, after loading some TSRs from FDAUTO.BAT (e.g. Bret Johnson's
> CLOCK), FreeCOM hangs, though I can't reliably reproduce that and loading
> the same TSRs manually works fine.
>
> 3. With the DIRCMD environment variable set to "/OGN/LFN" (possibly with
> other options), FreeCOM prints "Out of memory" instead of the expected long
> file names - but "/LFN" by itself works fine.
>
> I think this is still an improvement compared to the previous version (if
> compiled with OW), but the Turbo C++ version does not have any of these
> problems.
>
>
> --
> 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

--
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-pre3 prerelease

[Eric Auer]

Hi Matej,

> 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and
> DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel
> prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then
> right after that I see "Not enough memory" ...

Are you sure that this does not happen with older FreeCOM?

You often get weird memory problems around the time when
DOS starts using the HMA and other drivers or the shell
start using XMS and/or UMB, because this is the moment
when it becomes important that they really work stable.


> I think this is still an improvement compared to the previous version
> (if compiled with OW), but the Turbo C++ version does not have any of
> these problems.

Please explain :-)

Regards, Eric



--
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-pre3 prerelease

[Matej Horvat]

I found these bugs in the OW version so far:

1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and  
DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel  
prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right  
after that I see "Not enough memory" (not sure what prints that), and  
FreeCOM prints "The shell is about to be terminated, though, this is  
forbidden", etc., and hangs. Loading the same driver with DEVLOAD from  
FDAUTO.BAT works fine.


2. Sometimes, after loading some TSRs from FDAUTO.BAT (e.g. Bret Johnson's  
CLOCK), FreeCOM hangs, though I can't reliably reproduce that and loading  
the same TSRs manually works fine.


3. With the DIRCMD environment variable set to "/OGN/LFN" (possibly with  
other options), FreeCOM prints "Out of memory" instead of the expected  
long file names - but "/LFN" by itself works fine.


I think this is still an improvement compared to the previous version (if  
compiled with OW), but the Turbo C++ version does not have any of these  
problems.


--
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-pre3 prerelease

[Guti]

Thanks Bart.
Amazing OW build is more compact than TC one. Pretty fine!

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Remitente:Bart Oldeman <bartolde...@gmail.com>
Destinatario: Technical discussion and questions for FreeDOS developers. 
<freedos-devel@lists.sourceforge.net>
Fecha:sábado, 3 de febrero de 2018, 11:44:21
Asunto:       [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Archivos: 
--===--
Hi,

as some of you know I spent some time fixing various bugs in FreeCOM.
We've had the awkward situation of still having an old 2006 version in
distributions but the newer versions had too many bugs (e.g. loadhigh,
ren "myfile myfile.txt", strange dir output depending on the country
setting). However the newer versions support LFNs much better.

So for testing I uploaded a new prerelease on github:
https://github.com/bartoldeman/freecom/releases/tag/com084pre3

There are three non-UPXed xms-swap command.com's in the binary zip,
one compiled with Turbo C++ 1.01 (as the older version were), one
cross-compiled with OW 1.9 and one cross-compiled with ia16-elf-gcc.
Please test and let me know how stable they are in your testing.

As a bonus for the XMS swap version the resident footprint has been
reduced from 3008 bytes (old Turbo C version) to 2304 bytes (new OW
version).

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

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
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

[Freedos-devel] FreeCOM 0.84-pre3 prerelease

[Bart Oldeman]

Hi,

as some of you know I spent some time fixing various bugs in FreeCOM.
We've had the awkward situation of still having an old 2006 version in
distributions but the newer versions had too many bugs (e.g. loadhigh,
ren "myfile myfile.txt", strange dir output depending on the country
setting). However the newer versions support LFNs much better.

So for testing I uploaded a new prerelease on github:
https://github.com/bartoldeman/freecom/releases/tag/com084pre3

There are three non-UPXed xms-swap command.com's in the binary zip,
one compiled with Turbo C++ 1.01 (as the older version were), one
cross-compiled with OW 1.9 and one cross-compiled with ia16-elf-gcc.
Please test and let me know how stable they are in your testing.

As a bonus for the XMS swap version the resident footprint has been
reduced from 3008 bytes (old Turbo C version) to 2304 bytes (new OW
version).

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