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 22:20, Danilo Pecher via Freedos-devel wrote:
I would very much vote against replacing FreeDOS edit. I agree it is
bloated and not very well programmed, but instead of throwing it out,
we should make an effort to de-bloat and stream-line it.
There are at least two reasons for rev
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
I would very much vote against replacing FreeDOS edit. I agree it is
bloated and not very well programmed, but instead of throwing it out,
we should make an effort to de-bloat and stream-line it. FreeDOS was
created as as replacement/continuation of the original DOS, and as
such we should keep to t
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
On Tue, Feb 18, 2025 at 11:18 PM Bernd Böckmann
wrote:
> > I took a look, and it's really cool! I was thinking I'd probably want
> > to write something like this on my own, but wmincrt seems to do what
> > I'd want, so I'd like to incorporate it in DOG. :D
> > The header file seems to be under MI
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
Le mar., 18 févr. 2025 02:00:48 -0500 Paul Dufresne a écrit
>
> So would be:
> https://github.com/FDOS/freecom/commit/9ec47792953100eea6c9a18b0bed34a4471a9a6a
>
> that should fix: https://github.com/FDOS/freecom/issues/102
>
> but after that I:
> git bisect reset
> git
Hallo Herr perditionc--- via Freedos-devel,
am Dienstag, 18. Februar 2025 um 00:59 schrieben Sie:
> On Mon, Feb 17, 2025, 6:07 PM Victoria Crenshaw via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
>> I love this for testing!! We should test an newer kernel too lime thr git
>> ve
>
> You’re more than welcome to grab INT64.INC (using NASM) from V8Power Tools
> [1]. Or, you could port the functionality to a different assembler.
Thanks, will have a look at it! Using WASM is a hard requirement, as this is
the only assembler contained within the Watcom package. But porting s
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
18 matches
Mail list logo
