Hello Bart,
I fixed this issue now. There were issues with #pragma aux for OW and
for GCC inline asm.
The si parameter for XMScopy was not passed correctly for OW (likewise
for DS for GCC),
which meant that most XMScopy calls failed. However it would work by
accident because the strings usually
I fixed this issue now. There were issues with #pragma aux for OW and
for GCC inline asm.
The si parameter for XMScopy was not passed correctly for OW (likewise
for DS for GCC),
which meant that most XMScopy calls failed. However it would work by
accident because the strings usually simply stayed
Even simpler:
a:\system\sleep 1
dir /od/b
the first command is just to trigger one xms swap, and then after
swapping in "dir /od/b" (both flags are necessary) causes trouble.
Bart
--
Check out the vibrant tech
Ok, I am getting a bit closer after pruning fdauto.bat as much as possible:
this two-line fdauto.bat causes "String #" errors when typing dir in
metados for the OW command.com:
a:\system\shsurdrv /qq /d60M$SCRATCH,g
set /e FINDDO=dir /od/s/a-d/b a:\stubs.zip
looks like an issue with "set /e" so
Hello Bart,
now if the size of command.com in memory ever changes,
to little is saved/restored.
I think it is related somewhere to MCB corruption but still not sure where.
Somehow it happens after the strings are copied back in from XMS. I`ll
still have to dig deeper.
I have just checked in
Hello Tom,
unfortunately (thanks TK CHIA) sbreak() tries to increase the
size for malloc'ed memory. if it succeeds (and needed memory
is located behind SwapTransientSize: BAMM!
Thank you! I did find a bug concerning the swapping of the transient
portion to XMS, though it is of a different
Hello Tom,
On Sun, 26 Aug 2018 at 13:03, Tom Ehlert wrote:
> I think I found the cause for command crashing:
>
> the size to swap out, and back in, is only calculated once in
>XMSinit() {
>...
>mcb = MK_SEG_PTR (struct MCB, SEG2MCB (_psp));
>xms_block_size = SwapTransientSize =
Hallo Herr TK Chia,
am Freitag, 24. August 2018 um 18:52 schrieben Sie:
Hi all,
I think I found the cause for command crashing:
the size to swap out, and back in, is only calculated once in
XMSinit() {
...
mcb = MK_SEG_PTR (struct MCB, SEG2MCB (_psp));
xms_block_size =
Hello all,
I am still getting some very weird observations when look into why
FreeCOM weirds out:
When I recompiled FreeCOM on my end with GCC, and tried to run "fetch
mem" inside the METADOS setup, the command.com grew the heap area very
quickly when handling the complex batch files, and
Hello Tom, hello Rugxulo,
METADOS is a very advanced, very spaghetti BATCH project,
which in the end connects you with TCP, downloads components
(MEM.EXE below) from the internet and more interesting stuff.
unfortunately, *very* spaghetti.
.BAT doesn't have loops. It overuses "goto". It's not
In DOSbox info-zips zip16 and unzip runs fairly well (with cycles = max
95%) if I remember correctly
Den ons 22 aug. 2018 22:04Rugxulo skrev:
> Hi,
>
> On Wed, Aug 22, 2018, 7:07 AM Tom Ehlert wrote:
>
>>
>> as a side note: I have no experience with UNZIP.EXE in DOS, but I think
>> it's
AFAIK, VT-X is basically hardware-level support for virtualization and it does
help noticeably. Without it, the VM hypervisor must do all that work in
software. It kinda works like hardware acceleration for graphics in a video
card.
There's my two cents lol
Sent with
Hi,
On Wed, Aug 22, 2018, 7:07 AM Tom Ehlert wrote:
>
> as a side note: I have no experience with UNZIP.EXE in DOS, but I think
> it's performance pathetically slow. is this normal?
>
Under VM? Yes, "unzip" is specifically known to be much slower than normal.
I'm not exactly sure why. Like I
Hi Rugxulo,
> I know this was not a great bug report.
Yes indeed.
> In fact, I wasn't trying to be
> too specific, just mentioning that some random and confusing stuff was
> happening.
to start with, you didn't mention even METADOS, or even what version
of it, or even where to download it.
so
ble.
Laaca
-- Původní e-mail --
Od: Rugxulo
Komu: freedos-devel
Datum: 21. 8. 2018 21:22:04
Předmět: Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
"Hi again,
On Mon, Aug 20, 2018 at 12:25 PM Tom Ehlert wrote:
>
> more experiments.
>
> METADOS is a very adva
Hi again,
On Mon, Aug 20, 2018 at 12:25 PM Tom Ehlert wrote:
>
> more experiments.
>
> METADOS is a very advanced, very spaghetti BATCH project,
> which in the end connects you with TCP, downloads components
> (MEM.EXE below) from the internet and more interesting stuff.
> unfortunately, *very*
Hi, Tom,
I know this was not a great bug report. In fact, I wasn't trying to be
too specific, just mentioning that some random and confusing stuff was
happening. I didn't have time to isolate it yet. It was just a warning
that things weren't quite perfect yet. (But I appreciate your work,
Bart.)
On 2018-08-21 22:23 +0800, TK Chia wrote:
> However, both the intr ( ) implementation in Open Watcom, and the intr (
> ) implementation in suppl/src/intr.asm used when compiling with
> gcc-ia16, will _not_ try to load any flags --- including CF --- from
> reg.x.flags, so int 0x21 basically gets
Hi TK,
> However, both the intr ( ) implementation in Open Watcom, and the intr (
> ) implementation in suppl/src/intr.asm used when compiling with
> gcc-ia16, will _not_ try to load any flags --- including CF --- from
> reg.x.flags, so int 0x21 basically gets called with CF in an undefined
>
Hello all,
Meanwhile, for some reason I am also getting this error when starting
commandg.com under DOSBox (0.74-4.2 on Ubuntu):
[Out of memory loading STRINGS.]
Failed to load the strings resources into memory, the location
pointed to in %COMSPEC% seems to be invalid. Please specify
Hi Bart,
> Upon further investigation a mere allocation of
> orderArray = MK_SEG_PTR(void, DOSalloc(0x1000,2));
> before the main dir code and deallocating it at the end without even
> using orderArray for sorting already corrupts things.
> I suspect that the memory block used for the message
Upon further investigation a mere allocation of
orderArray = MK_SEG_PTR(void, DOSalloc(0x1000,2));
before the main dir code and deallocating it at the end without even
using orderArray for sorting already corrupts things.
I suspect that the memory block used for the message strings is
getting in
This change seems to be the cause (which was motivated by the fact
that otherwise with large memory model regular malloc's would fail as
they bumped into the allocated memory block)
--- a/cmd/dir.c
+++ b/cmd/dir.c
@@ -1010,7 +1010,8 @@ static int dir_list(int pathlen
error_out_of_memory();
more experiments.
METADOS is a very advanced, very spaghetti BATCH project,
which in the end connects you with TCP, downloads components
(MEM.EXE below) from the internet and more interesting stuff.
unfortunately, *very* spaghetti.
anyway, FreeCOM 0.84-pre5 prerelease doesn't behave a) as
Hi everybody,
>> Thanks for your efforts, of course, but ... it's still got some
>> bugs. The Watcom build runs faster (oddly),
> could you please enlighten the rest of the universe in what way you
> determined that 'The Watcom build runs faster'
ok, I enlightened myself, downloaded
Hi Tom,
> can we please have a new version number please.
>
> instead of
>FreeCOM 0.84-pre5 prerelease beta 1
>
> FreeCOM 0.85 prerelease
That does not make much sense to me since 0.84 has not yet been released yet.
there is no beta1 (not sure where you read that, if it's there by
accident
Hi Eric,
On Thu, 16 Aug 2018 at 04:24, Eric Auer wrote:
> Could you tell more about the comResFile
> memory leak? Does it fix an old, elusive
> bug which has been on the list repeatedly?
no, it's not an old bug, it's related to getEnv("COMSPEC") using
dynamic pointers (since pre3) and the
Hi Bart,
can we please have a new version number please.
instead of
FreeCOM 0.84-pre5 prerelease beta 1
FreeCOM 0.85 prerelease
Tom
--
Check out the vibrant tech community on one of the world's most
engaging tech
> Thanks for your efforts, of course, but ... it's still got some
> bugs. The Watcom build runs faster (oddly),
could you please enlighten the rest of the universe in what way you
determined that 'The Watcom build runs faster'
> but my TESTS.BAT
' my TESTS.BAT' ? are we assumed to know
Hello Ruxgulo, hello Bart,
Thanks for your efforts, of course, but ... it's still got some bugs. The
Watcom build runs faster (oddly), but my TESTS.BAT just silently fails. And
the others (Turbo and GCC) seem to later on cause "Invalid Opcode". So I
haven't weakly tried isolating that yet. I
Hi,
On Wed, Aug 15, 2018, 7:51 PM Bart Oldeman wrote:
>
> thanks again everybody for the feedback. I now updated the prerelease to
> pre5 with a few changes and bug fixes,
>
Thanks for your efforts, of course, but ... it's still got some bugs. The
Watcom build runs faster (oddly), but my
Hi Bart,
cool to hear about those FreeCOM updates!
Could you tell more about the comResFile
memory leak? Does it fix an old, elusive
bug which has been on the list repeatedly?
Thanks for the updates!
Eric
--
Check
Hi,
thanks again everybody for the feedback. I now updated the prerelease to
pre5 with a few changes and bug fixes, most importantly:
* Update translations (Serbian/Slovene/Turkish/French)
* fixed: FOR %i IN (*.*) do @ECHO %i does not work
* fixed: The shell doesn't display any error if exec
33 matches
Mail list logo
