Closed andrewbird closed 9 months ago
I think its already fixed by https://github.com/dosemu2/comcom64/commit/fc0b874a6e8f23f5fc90901afc834cd4b8003d84
But I am not sure as I am using a different stub where that problem doesn't trigger at all.
Thanks, I'll check that out as soon as the PPA gets updated.
PPA package was updated today and now the odd character is gone, thanks!
Cool! I actually forced the rebuild for you, because I want to replace the stub with a new one, and your ticket was holding that process. :)
Btw, as you are the last user of
the old stub, could you please see
the mem
output?
I suspect the old stub consumed
much more than the new one will.
Is that freedos mem, as I'll have to install it?
No one have written built-in mem
yet, so insfdusr
(given that you have
install-freedos scripts installed).
Here you go:
And (with -td)
C:\>mem /u
Segment Total Name Type
------- ---------------- ------------ -------------
04bf 54.944 (54K) MEM program
122a 580.928 (567K) free
a000 176 (0K) free
a426 81.280 (79K) free
c000 14.064 (14K) DOS system data
c002 144 (0K) EMS device driver
c00c 160 (0K) EMUFS device driver
c017 784 (1K) CDROM device driver
c370 4.336 (4K) COMMAND program
c480 112.608 (110K) free
f000 40.944 (40K) free
Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 640K 19K 621K
Upper 264K 34K 230K
Reserved 120K 120K 0K
Extended (XMS) 16.384K 0K 16.384K
---------------- -------- -------- --------
Total memory 17.408K 173K 17.235K
Total under 1 MB 904K 53K 851K
Total Expanded (EMS) 8.576K (8.781.824 bytes)
Free Expanded (EMS) 8.128K (8.323.072 bytes)
Largest executable program size 621K (635.888 bytes)
Largest free upper memory block 110K (112.624 bytes)
Thanks! After the next update you'll get a much better stats. :)
New build is awaiting for you. :)
I updated.
C:\>ver /r
comcom64 v0.3, dj64 (C) stsp
Reported DOS version (Int21.3000): 5.00 OEM: FDh
Reported true DOS version (Int21.3306): 7.10
Version string (Int21.33FF): FDPP kernel 1.7 [GIT: ] (compiled Mar 8 2024)
C:\>mem /u
Segment Total Name Type
------- ---------------- ------------ -------------
00b3 54.944 (54K) MEM program
0e1e 597.504 (584K) free
a000 176 (0K) free
a00c 67.536 (66K) COMMAND program
b58e 9.984 (10K) free
c000 14.064 (14K) DOS system data
c002 144 (0K) EMS device driver
c00c 160 (0K) EMUFS device driver
c017 784 (1K) CDROM device driver
c370 116.960 (114K) free
f000 40.944 (40K) free
Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 640K 3K 637K
Upper 264K 100K 164K
Reserved 120K 120K 0K
Extended (XMS) 16.384K 0K 16.384K
---------------- -------- -------- --------
Total memory 17.408K 223K 17.185K
Total under 1 MB 904K 103K 801K
Total Expanded (EMS) 8.576K (8.781.824 bytes)
Free Expanded (EMS) 8.128K (8.323.072 bytes)
Largest executable program size 637K (652.464 bytes)
Largest free upper memory block 114K (116.976 bytes)
Isn't that more memory used?
Well, conventional memory is used only by 3K, and not by command.com. But UMB... Yes, seems some excessive use is here.
I think if you update now, the numbers would be different.
Here you go
C:\>ver /r
comcom64 v0.3, dj64 (C) stsp
Reported DOS version (Int21.3000): 5.00 OEM: FDh
Reported true DOS version (Int21.3306): 7.10
Version string (Int21.33FF): FDPP kernel 1.7 [GIT: ] (compiled Mar 10 2024)
C:\>mem /u
Segment Total Name Type
------- ---------------- ------------ -------------
00b3 54.944 (54K) MEM program
0e1e 597.504 (584K) free
a000 176 (0K) free
a00c 67.536 (66K) COMMAND program
b58e 9.984 (10K) free
c000 14.064 (14K) DOS system data
c002 144 (0K) EMS device driver
c00c 160 (0K) EMUFS device driver
c017 784 (1K) CDROM device driver
c370 116.960 (114K) free
f000 40.944 (40K) free
Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 640K 3K 637K
Upper 264K 100K 164K
Reserved 120K 120K 0K
Extended (XMS) 16.384K 0K 16.384K
---------------- -------- -------- --------
Total memory 17.408K 223K 17.185K
Total under 1 MB 904K 103K 801K
Total Expanded (EMS) 8.576K (8.781.824 bytes)
Free Expanded (EMS) 8.128K (8.323.072 bytes)
Largest executable program size 637K (652.464 bytes)
Largest free upper memory block 114K (116.976 bytes)
Mmm, actually I only got an FDPP update and not comcom, so the numbers didn't change.
There is something wrong on LP: the arm64 builds are now waiting for 6-10 hours before being built, but the x86_64 builds process rapidly. But maybe the x86_64 builds are not published w/o arm64 ones? Lets wait a bit more... :(
Wow!
C:\>ver /r
comcom64 v0.3, dj64 (C) stsp
Reported DOS version (Int21.3000): 5.00 OEM: FDh
Reported true DOS version (Int21.3306): 7.10
Version string (Int21.33FF): FDPP kernel 1.7 [GIT: ] (compiled Mar 10 2024)
C:\>mem /u
Segment Total Name Type
------- ---------------- ------------ -------------
00b3 54.944 (54K) MEM program
0e1e 597.504 (584K) free
a000 176 (0K) free
a00c 256 (0K) COMMAND program
a437 50.464 (49K) free
b174 26.784 (26K) free
c000 14.064 (14K) DOS system data
c002 144 (0K) EMS device driver
c00c 160 (0K) EMUFS device driver
c017 784 (1K) CDROM device driver
c370 116.960 (114K) free
f000 40.944 (40K) free
Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 640K 3K 637K
Upper 264K 34K 230K
Reserved 120K 120K 0K
Extended (XMS) 16.384K 0K 16.384K
---------------- -------- -------- --------
Total memory 17.408K 157K 17.251K
Total under 1 MB 904K 37K 867K
Total Expanded (EMS) 8.576K (8.781.824 bytes)
Free Expanded (EMS) 8.128K (8.323.072 bytes)
Largest executable program size 637K (652.464 bytes)
Largest free upper memory block 114K (116.976 bytes)
Wow! a00c 256 (0K) COMMAND program
Yes, I was always wondering why the prot-mode program consumes the conventional memory in a large quantities... 0K is quite an answer: it shouldn't. :)
Not sure what the last character signifies on
ver /r
comcom64 string.I'm in the UK, so I expect my codepage is 858