Hallo Herr Bernd Böckmann via Freedos-devel,
am Donnerstag, 20. Februar 2025 um 00:11 schrieben Sie:
> Hello Jeremy,
> On 20.02.2025 00:03, perditi...@gmail.com wrote:
>> Thanks for looking into it. I will have a look at Watcom build and > see
>> why it's not patching header.
> Have a look
Hello Jeremy,
On 20.02.2025 00:03, perditi...@gmail.com wrote:
Thanks for looking into it. I will have a look at Watcom build and
see why it's not patching header.
Have a look at
https://github.com/FDOS/freecom/blob/fa674ea7b5aa4fcb0e4b4263d9ba31d79ccfc961/tools/ptchsize.c#L276
;)
While
Thanks for looking into it. I will have a look at Watcom build and see why
it's not patching header.
Jeremy
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
On 19.02.2025 23:10, Bernd Böckmann via Freedos-devel wrote:
I saw that the word at 0x0A is 0x2B1 for v0.85a
This was actually the GCC build of master, not the v0.85a Watcom build.
I messed up my eight simultaneously open COMMAND.COM tabs in hexedit.
But I think the conclusion I drew earlier
On 19.02.2025 22:35, Bernd Böckmann via Freedos-devel wrote:
I saw that the word at 0x0A is 0x2B1 for v0.85a, where it is 0x118 for
0.86. But 0x118 is an impossible value for ptchsize +6KB
This rather seems to be a result of ptchsize not patching the minimum
needed additional memory when buil
Hello Tom,
On 19.02.2025 22:17, tom ehlert via Freedos-devel wrote:
Requiring minimum load size of 87K makes it load low
The 87K I mentioned were the free UMA memory for which the unaltered
0.86 binary worked for me in connection with SHELLHIGH, after I
instructed JEMMEX to include the memo
Hallo Herr Bernd Böckmann via Freedos-devel,
am Mittwoch, 19. Februar 2025 um 21:05 schrieben Sie:
> I agree with Tom that changing the EXE header should be to way to go.
> I did a quick test by patching the COMMAND.COM header by hand with a hex
> editor.
> When I patch offset 0x0A to be 0x400
Replying here since I'm having trouble finding the place where exemod was
actually mentioned.
On Wed, 19 Feb 2025, Bernd Böckmann via Freedos-devel wrote:
I agree with Tom that changing the EXE header should be to way to go.
I wrote a replacement for exemod last year, but I never got around
I agree with Tom that changing the EXE header should be to way to go.
I did a quick test by patching the COMMAND.COM header by hand with a hex
editor.
When I patch offset 0x0A to be 0x400 (16k additional memory), total
initial allocation size becomes ~80K.
That patched binary works, as it d
Hallo Herr Bernd Böckmann via Freedos-devel,
am Mittwoch, 19. Februar 2025 um 12:31 schrieben Sie:
>> Am 19.02.2025 um 09:51 schrieb Bernd Böckmann via Freedos-devel
>> :
>>
>> As previously stated, a significant portion of upper memory is not available
>> under VMware. So we should further t
Forcing JEMMEX to use the memory region C900-DFFF results in 87K free in the
UMA, and that is sufficient to make FreeCOM work when loaded via SHELLHIGH,
meaning not terminating with an out of memory error.
DEVICE=C:\FREEDOS\BIN\JEMMEX.EXE NOEMS I=C900-DFFF
But this line is likely to have uninte
> Am 19.02.2025 um 09:51 schrieb Bernd Böckmann via Freedos-devel
> :
>
> As previously stated, a significant portion of upper memory is not available
> under VMware. So we should further try to figure out why this is the case.
>
> Screenshots are at:
> https://nextcloud.iww.rwth-aachen.de/ind
I dumped memory maps for boot options 1 and 2 under VMware via
INSTALL=C:\FREEDOS\BIN\MEM.EXE /D /P
There is 69K of upper memory available. Seems that this is sufficient for the
kernel to load the command interpreter high via SHELLHIGH. But most likely then
FreeCOM fails to allocate additional
Since you did not reply much to my question... I asked my prefered A.I.
Here what it says:
This first question is less relevant... you could skip to the
Me: In FreeDOS, I see that FreeCom seems to sometimes miss memory to allocate
command line (40 bytes) in shell/init..
14 matches
Mail list logo