dosemu-devel Mailing List for DOSEMU for Linux (Page 3)
Brought to you by:
bartoldeman
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(4) |
Apr
(5) |
May
(17) |
Jun
(9) |
Jul
|
Aug
(4) |
Sep
(2) |
Oct
(20) |
Nov
(16) |
Dec
(35) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(138) |
Feb
(104) |
Mar
(20) |
Apr
(14) |
May
(26) |
Jun
(13) |
Jul
(8) |
Aug
(20) |
Sep
(4) |
Oct
|
Nov
(21) |
Dec
|
2004 |
Jan
(22) |
Feb
(8) |
Mar
(17) |
Apr
(25) |
May
(12) |
Jun
(17) |
Jul
(9) |
Aug
(1) |
Sep
(31) |
Oct
(5) |
Nov
(20) |
Dec
(7) |
2005 |
Jan
|
Feb
(2) |
Mar
(11) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(42) |
Aug
(13) |
Sep
(7) |
Oct
|
Nov
(31) |
Dec
(36) |
2006 |
Jan
(25) |
Feb
(9) |
Mar
(37) |
Apr
(13) |
May
(11) |
Jun
(2) |
Jul
|
Aug
(9) |
Sep
|
Oct
(11) |
Nov
(13) |
Dec
|
2007 |
Jan
(4) |
Feb
(3) |
Mar
(3) |
Apr
(6) |
May
(6) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
2008 |
Jan
|
Feb
(12) |
Mar
(1) |
Apr
(6) |
May
(9) |
Jun
|
Jul
(7) |
Aug
(3) |
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
2009 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(6) |
May
(11) |
Jun
(3) |
Jul
(2) |
Aug
(10) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(48) |
May
(25) |
Jun
|
Jul
|
Aug
(5) |
Sep
(1) |
Oct
(23) |
Nov
(25) |
Dec
(22) |
2013 |
Jan
(37) |
Feb
(13) |
Mar
(15) |
Apr
(4) |
May
|
Jun
(48) |
Jul
(36) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2014 |
Jan
|
Feb
|
Mar
(4) |
Apr
(20) |
May
(19) |
Jun
(18) |
Jul
|
Aug
|
Sep
(9) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(11) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Stas S. <st...@li...> - 2014-06-01 08:36:07
|
30.05.2014 01:39, Julius Schwartzenberg пишет: > Yes, of course. But it'd still be really cool if it could work in > DOSEMU :) Were you running it after booting in its own DOS? It will not work with freedos or even MS-DOS other than its own. Also, are you aware about HX dos extender? It has a win32 support built-in and works in dosemu. Of course I admit that running a kind of win95 would be a good demo of dosemu's abilities. :) |
From: Stas S. <st...@li...> - 2014-05-30 10:59:44
|
30.05.2014 01:36, Julius Schwartzenberg пишет: > Stas Sergeev wrote: >> 29.05.2014 14:22, Julius Schwartzenberg пишет: >>> When I run win.com from Chicago in DOSEMU, I immediately get my prompt >>> back. It seems nothing happens then. Could it be possible that some >>> detection that Windows is already running is triggered and that win.com >>> is written to not do anything then? >> Hi, the windows loading is done with the tricks. >> When win.com wants to run win386.exe, dosemu instead runs >> krnl386.exe, etc. It has some code stolen from wine to provide >> the vxd services that otherwise win386.exe would provide. >> I think this is not what win95 likes. > Ah, I didn't know there was so much trickery behind running Windows 3.1 :) Dosemu doesn't support the ring-0 execution. Fortunately, windows-3.1 appeared to be just a DPMI client (with dpmi server in win386.exe, but dosemu bypasses that). The only ring-0 stuff it does is LDT management, which we emulate. > Yes, of course. But it'd still be really cool if it could work in DOSEMU Likely. But how many real win32 apps do work on early alpha of win95? I guess none. |
From: Julius S. <jul...@gm...> - 2014-05-29 21:37:08
|
Stas Sergeev wrote: > 29.05.2014 14:22, Julius Schwartzenberg пишет: >> When I run win.com from Chicago in DOSEMU, I immediately get my prompt >> back. It seems nothing happens then. Could it be possible that some >> detection that Windows is already running is triggered and that win.com >> is written to not do anything then? > Hi, the windows loading is done with the tricks. > When win.com wants to run win386.exe, dosemu instead runs > krnl386.exe, etc. It has some code stolen from wine to provide > the vxd services that otherwise win386.exe would provide. > I think this is not what win95 likes. Ah, I didn't know there was so much trickery behind running Windows 3.1 :) Then indeed just blindly running Chicago probably won't work. |
From: Stas S. <st...@li...> - 2014-05-29 11:42:47
|
29.05.2014 14:22, Julius Schwartzenberg пишет: > Hi, > > When I run win.com from Chicago in DOSEMU, I immediately get my prompt > back. It seems nothing happens then. Could it be possible that some > detection that Windows is already running is triggered and that win.com > is written to not do anything then? Hi, the windows loading is done with the tricks. When win.com wants to run win386.exe, dosemu instead runs krnl386.exe, etc. It has some code stolen from wine to provide the vxd services that otherwise win386.exe would provide. I think this is not what win95 likes. > Did anybody every try to run Chicago in DOSEMU? There were rumours that Chicago is built on the kernel of win3.11 (and later changed a lot), so 10 years ago I wanted to try that myself, but unfortunately Chicago was not available for download. Anyway, I think wine is better on running windows apps, even if dosemu could run win95. |
From: Julius S. <jul...@gm...> - 2014-05-29 10:42:38
|
Hi, When I run win.com from Chicago in DOSEMU, I immediately get my prompt back. It seems nothing happens then. Could it be possible that some detection that Windows is already running is triggered and that win.com is written to not do anything then? Did anybody every try to run Chicago in DOSEMU? Best regards, Julius |
From: Frantisek H. <fr...@ha...> - 2014-05-28 09:42:24
|
Reinhard Karcher wrote: > Am Mittwoch, 28. Mai 2014, 10:14:10 schrieb Frantisek Hanzlik: >> Hello Stas, >> >> if I understand it from Your last devel branch changes, from Linux >> kernel 3.14+ will no longer be possible to use DPMI on i386 systems >> in VM86 mode? >> It would be annoying thing for me, because I use 32-bit systems for >> all my DOS apps, due to significantly higher performance over both >> emulation modes. >> Please, what is reason for this step? Linux kernel developers have >> always emphasized the need for kernel API preservation, what happened >> in this case? >> It will affect other emulators (wine, qemu) too? > > Hello Franta, > > as far as I know, the change only affects 64-bit kernels. It was > introduces because of an information leak with 16-Bit dmpi applications. > Linus committed a change to restore the old behavior online. > I created a file ldt16.conf in /etc/sysctl.d/ containing the line: > abi.ldt16 = 1 > and got the old behavior after reboot. You could also use the command: > echo 1 > /proc/sys/abi/ldt16 > to change your kernel without reboot. > Linus mentioned complaints from wine users. > The commit to the linux kernel with the workaround is: > fa81511bb0bbb2b1aace3695ce869da9762624ff > > Reinhard Hi Reinhard and Stas, thank You for the explanation. |
From: Reinhard K. <rei...@gm...> - 2014-05-28 09:10:54
|
Am Mittwoch, 28. Mai 2014, 10:14:10 schrieb Frantisek Hanzlik: > Hello Stas, > > if I understand it from Your last devel branch changes, from Linux > kernel 3.14+ will no longer be possible to use DPMI on i386 systems > in VM86 mode? > It would be annoying thing for me, because I use 32-bit systems for > all my DOS apps, due to significantly higher performance over both > emulation modes. > Please, what is reason for this step? Linux kernel developers have > always emphasized the need for kernel API preservation, what happened > in this case? > It will affect other emulators (wine, qemu) too? Hello Franta, as far as I know, the change only affects 64-bit kernels. It was introduces because of an information leak with 16-Bit dmpi applications. Linus committed a change to restore the old behavior online. I created a file ldt16.conf in /etc/sysctl.d/ containing the line: abi.ldt16 = 1 and got the old behavior after reboot. You could also use the command: echo 1 > /proc/sys/abi/ldt16 to change your kernel without reboot. Linus mentioned complaints from wine users. The commit to the linux kernel with the workaround is: fa81511bb0bbb2b1aace3695ce869da9762624ff Reinhard |
From: Stas S. <st...@li...> - 2014-05-28 09:06:46
|
28.05.2014 12:14, Frantisek Hanzlik пишет: > Hello Stas, > > if I understand it from Your last devel branch changes, from Linux > kernel 3.14+ will no longer be possible to use DPMI on i386 systems > in VM86 mode? DPMI in vm86 mode? :) No, this has nothing to do with 32bit systems and with vm86, but DPMI stops working. > It will affect other emulators (wine, qemu) too? Wine - yes (to the very small extent), qemu - no. Maybe they will restore the functionality in the future. |
From: Frantisek H. <fr...@ha...> - 2014-05-28 08:14:23
|
Hello Stas, if I understand it from Your last devel branch changes, from Linux kernel 3.14+ will no longer be possible to use DPMI on i386 systems in VM86 mode? It would be annoying thing for me, because I use 32-bit systems for all my DOS apps, due to significantly higher performance over both emulation modes. Please, what is reason for this step? Linux kernel developers have always emphasized the need for kernel API preservation, what happened in this case? It will affect other emulators (wine, qemu) too? Thanks, Franta |
From: Stas S. <st...@li...> - 2014-05-13 14:19:42
|
13.05.2014 17:45, Frantisek Hanzlik пишет: > Stas Sergeev wrote: >> 05.05.2014 16:26, Frantisek Hanzlik пишет: >>> Hi Bart and all, >>> >>> hoping that it will be useful, I have mapped and updated some >>> dosemu-freedos utilities to their current versions. >>> Thanks to the peoples of dosemu and FreeDOS mailing list for their >>> comments. >>> Updated package may be downloaded at: >>> http://www.hanzlici.cz/packages/dosemu-freedos/dosemu-freedos-1.1-pre1-bin.tgz >> Note that this doesn't even exist, 404. > Excuse for this and thanks for notice. On the last Sunday done system > updates (in the concrete munin-cgi) cause this problem. Now should > be this reference fine. Thanks. There are also another similar attempts: https://sourceforge.net/p/dosemu/feature-requests/63/ Someone needs to take a look. |
From: Frantisek H. <fr...@ha...> - 2014-05-13 13:45:35
|
Stas Sergeev wrote: > 05.05.2014 16:26, Frantisek Hanzlik пишет: >> Hi Bart and all, >> >> hoping that it will be useful, I have mapped and updated some >> dosemu-freedos utilities to their current versions. >> Thanks to the peoples of dosemu and FreeDOS mailing list for their >> comments. >> Updated package may be downloaded at: >> http://www.hanzlici.cz/packages/dosemu-freedos/dosemu-freedos-1.1-pre1-bin.tgz > > Note that this doesn't even exist, 404. Excuse for this and thanks for notice. On the last Sunday done system updates (in the concrete munin-cgi) cause this problem. Now should be this reference fine. Franta Hanzlik |
From: Stas S. <st...@li...> - 2014-05-13 13:08:23
|
05.05.2014 16:26, Frantisek Hanzlik пишет: > Hi Bart and all, > > Luční 502 Linux/Unix/LAN/Internet Tel: +420-372-222302 > 33209 Štěnovice e-mail:fr...@ha... Fax: +420-372-222302 > hoping that it will be useful, I have mapped and updated some > dosemu-freedos utilities to their current versions. > Thanks to the peoples of dosemu and FreeDOS mailing list for their > comments. > Updated package may be downloaded at: > http://www.hanzlici.cz/packages/dosemu-freedos/dosemu-freedos-1.1-pre1-bin.tgz Note that this doesn't even exist, 404. |
From: Stas S. <st...@li...> - 2014-05-05 13:04:44
|
05.05.2014 16:26, Frantisek Hanzlik пишет: > * maybe some file manager would be useful (Volkov beta, Necromancer, > etc). Not sure, when their licences permit their use with > DOSEMU/FreeDOS I am not a freedos user, so my opinion in that area doesn't count much, but I think having some FM would be cool. Also, DosNavigator (necromancer etc) license seems rather permissive to allow it to be included in the package. What will not be allowed is to include that package in some distro, like fedora or debian, but the package itself should be fine I think. Making dosemu-freedos package acceptable for distros is almost an unrealistic task anyway, so making it slightly worse by adding a few more packages doesn't sound all that bad. Of course you can try to find some GPLed FM compiled with djgpp. > * I would love some GNU utils as awk, sed, find,... Just for what? dosemu allows you to access the native tools, so I think for dosemu-freedos those are of a small value. > - what about GNU basic utils (cat, cmp, cp, cut, grep, head, ls, mv, > rm, tac, tail) in current package? They was build somewhile 20+ years > ago - but probably do what they have - maybe except grep, which had > some bigger evolution. What I found newer, was only DJGPP utilities, > but I'm not sure when they are suitable for including into DOSEMU > FreeDOS - it semm for me, that they may have greater memory > requirements (although use DPMI) and I do not know whether is fair > idea of the program from which I start the script, in which is > chained several GNU utilities in one pipeline (as is common in Un*x). I am sure memory requirements for djgpp-compiled progs are not a problem under dosemu, as you say they use DPMI. |
From: Frantisek H. <fr...@ha...> - 2014-05-05 12:27:09
|
Hi Bart and all, Luční 502 Linux/Unix/LAN/Internet Tel: +420-372-222302 33209 Štěnovice e-mail:fr...@ha... Fax: +420-372-222302 hoping that it will be useful, I have mapped and updated some dosemu-freedos utilities to their current versions. Thanks to the peoples of dosemu and FreeDOS mailing list for their comments. Updated package may be downloaded at: http://www.hanzlici.cz/packages/dosemu-freedos/dosemu-freedos-1.1-pre1-bin.tgz Changes between dosemu-freedos-1.0 and this updated version may be described as (if isn't new version, then component remained the same): COMPONENT CurVers NewVers COMMENT assign 1.4 attrib 2.1 bwbasic 2.20 -> 2.50 (with OpenWatcom patch?) choice 4.4 command 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00] comp 1.03 #retained, current 1.04 has only copyright added) cpidos 2.0 -> 3.0 debug.com 0.98 -> 1.26 deltree 1.02f -> 1.02g diskcomp 06jun2003 diskcopy 0.94 beta -> 0.95 beta display 0.13b edit 0.7d -> 0.9a # 0.7d was UPXed, 0.9a not edlin 2.8 -> 2.15 exe2bin 1.0 -> 1.5 # Copying-policy: GPL -> OW Public License fc 3.03 find 2.9 -> 3.0a format 0.91v FastHelp Suite 2004 join,swsubst 3.2 kernel.sys 2036 -> 2041 label 1.4b lib.exe 3.2 mem 1.10 -> 1.11 mode 12may2005 more 4.2 -> 4.3 (lfn support) move 3.3a nansi.sys 4.0b -> 4.0d replace 1.2 share 08_2006 sort 1.2 -> 1.5 (lfn support) subst(swsubst) 3.2 sys 2036 -> 2041 tee 1.0 -> 2.0.3 (not UPXed .com -> un-UPXed .exe) touch 1.4.3 -> 1.4.4 tree 3.7.2 wcd 3.2.0 (retained, as current v5.2.4 seems be too big) xcopy 1.2 -> 1.4a (rxcopy) Regarding UPX packaging - I leave TSRs (display, nansi, share) not UPXed, and other packages are same as their maintainers have it in their FreeDOS package archives (I took them from sunsite archive: ftp://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/files/ ) However, there are still some vagueness and questions: - is important somehow adhere total package size (current v1.0 .tgz size is ~ 1.2 MB, updated is ~ 1.3 MB) ? IMO it isn't so crucial, as Linux distro has usualy several gigabytes and dosemu-freedos files are in system installed only once (users has usualy only symlink to them) - Are some programs in current package unnecessary for average user? (e.g. lib.exe / bwbasic / exe2bin / wcd are maybe only rarely used ?) - It would be good to add some packages? * Maybe fdnpkg/fdupdate would be useful (but they perhaps would have to be used only by root due to Linux permission restrictions) * maybe some file manager would be useful (Volkov beta, Necromancer, etc). Not sure, when their licences permit their use with DOSEMU/FreeDOS * I would love some GNU utils as awk, sed, find,... * some archiver (7zip, xz,..) would be useful too - what about GNU basic utils (cat, cmp, cp, cut, grep, head, ls, mv, rm, tac, tail) in current package? They was build somewhile 20+ years ago - but probably do what they have - maybe except grep, which had some bigger evolution. What I found newer, was only DJGPP utilities, but I'm not sure when they are suitable for including into DOSEMU FreeDOS - it semm for me, that they may have greater memory requirements (although use DPMI) and I do not know whether is fair idea of the program from which I start the script, in which is chained several GNU utilities in one pipeline (as is common in Un*x). Can You please give me some comments to the above? Thanks, Franta Hanzlik |
From: Frantisek H. <fr...@ha...> - 2014-05-05 12:05:22
|
Stas Sergeev wrote: > 05.05.2014 11:55, Frantisek Hanzlik пишет: >> Stas Sergeev wrote: >>> 04.05.2014 02:33, Frantisek Hanzlik пишет: >>>> Hi DOSEMU and FreDOS developers, >>>> >>>> FreeDOS 'more' command (tried both 4.2 and 4.3 versions) isn't working >>>> correctly under DOSEMU when used in screen resolutions other than 80 >>>> columns x 25 rows. From its code (function GetScreenSize() in more.c) >>>> it seems as more compute no. of screen rows from BIOS data area, from >>>> 40h:4Ah (Columns on screen) and 40h:4Ch (Video page size) values, >>>> using formula: >>>> ROWS=Video page size / Columns on screen / 2 >>>> >>>> which in this case give bad results, as Video page sizes are multiples >>>> of 4k (number of columns is OK). Here is what Video page size values >>>> are returned in certain text modes: >>>> >>>> 80x25 - 40:4C=0x1000=4096, more has 25 rows. 80x25x2=4000=0xFA0 >>>> 80x43 - 40:4C=0x2000=8192, more has 51 rows. 80x43x2=6880=0x1AE0 >>>> 80x50 - 40:4C=0x2000=8192, more has 51 rows. 80x50x2=8000=0x1F40 >>>> 80x60 - 40:4C=0x3000=12288, more has 76 rows. 80x60x2=9600=0x2580 >>>> 132x25 - 40:4C=0x2000=8192, more has 31 rows. 132x25x2=6600=0x19C8 >>>> 132x43 - 40:4C=0x3000=12288, more has 46 rows. 132x43x2=11352=0x2C58 >>>> 132x60 - 40:4C=0x4000=16384, more has 62 rows. 132x60x2=15840=0x3DE0 >>>> >>>> >From some informations on net (e.g. here: >>>> http://marc.info/?l=freedos-dev&m=106291977718089&w=2 >>>> ) it seems as video page size isn't reliable/suitable for no. of rows >>>> on screen computing - but I'm not sure, as this may be DOSEMU bug >>>> as well. I want to report a bug, but what? DOSEMU, or 'more' command? >>> I think it is a bug in dosemu (or both). >>> I am currently experimenting with bochs vgabios, and >>> it has different page alignment than the one of dosemu. >>> Namely: >>> >>> -#define TEXT_SIZE(co,li) (((co*li*2)+4095)&(~4095)) /* 4000(4096?) >>> text page size */ >>> +#define TEXT_SIZE(co,li) (((co*li*2)|0xff)+1) >>> >>> >>> So please try 'vbios_tweaks' branch and see if maybe mode >>> is now fine? >> Just trying dosemu-1.4.0.8-git647.gf966688.fc19.i686. But when now >> is video page size calculated as You mentioned above (i.e. rounded up >> to the 256 byte boundary), then still isn't possible take video page >> size for no. of screen rows calculating - there may be deviation from >> the correct value up to (128 / cols). E.g. when running 'dosemu -t' >> in xterm window 40 cols x 48 lines, then Your video page size/ >> TEXT_SIZE=4096, from which 'more' calculate 4096 / 40 / 2 = 51.2; >> thus it will consider that screen has 51 lines - three more than >> in reality. >> For 'usual' VBE defined modes is situation better: >> >> 80x25, VidPgSz= 4096, more has: 25.60== 25 rows, delta=0. >> 80x43, VidPgSz= 6912, more has: 43.20== 43 rows, delta=0. >> 80x50, VidPgSz= 8192, more has: 51.20== 51 rows, delta=1. >> 80x60, VidPgSz= 9728, more has: 60.80== 60 rows, delta=0. >> 132x25, VidPgSz= 6656, more has: 25.21== 25 rows, delta=0. >> 132x43, VidPgSz=11520, more has: 43.64== 43 rows, delta=0. >> 132x50, VidPgSz=13312, more has: 50.42== 50 rows, delta=0. >> 132x60, VidPgSz=15872, more has: 60.12== 60 rows, delta=0. >> >> thus only 80 cols x 50 rows is affected (with 1 line difference) >> >> Anyhow, FreeDOS 'mode con' in any resolution works fine and display >> correct cols and rows numbers (I not know how did it). > OK, thanks for testing. > So have they looked into your patch? I only sent mail to Imre Leber, which is listed as "more" maintainer, but it was before not even thirty hours. Now I just fill bug about: https://sourceforge.net/p/freedos/bugs/119/ which contains roughly that what I wrote to Imre. |
From: Stas S. <st...@li...> - 2014-05-05 10:01:34
|
05.05.2014 11:55, Frantisek Hanzlik пишет: > Stas Sergeev wrote: >> 04.05.2014 02:33, Frantisek Hanzlik пишет: >>> Hi DOSEMU and FreDOS developers, >>> >>> FreeDOS 'more' command (tried both 4.2 and 4.3 versions) isn't working >>> correctly under DOSEMU when used in screen resolutions other than 80 >>> columns x 25 rows. From its code (function GetScreenSize() in more.c) >>> it seems as more compute no. of screen rows from BIOS data area, from >>> 40h:4Ah (Columns on screen) and 40h:4Ch (Video page size) values, >>> using formula: >>> ROWS=Video page size / Columns on screen / 2 >>> >>> which in this case give bad results, as Video page sizes are multiples >>> of 4k (number of columns is OK). Here is what Video page size values >>> are returned in certain text modes: >>> >>> 80x25 - 40:4C=0x1000=4096, more has 25 rows. 80x25x2=4000=0xFA0 >>> 80x43 - 40:4C=0x2000=8192, more has 51 rows. 80x43x2=6880=0x1AE0 >>> 80x50 - 40:4C=0x2000=8192, more has 51 rows. 80x50x2=8000=0x1F40 >>> 80x60 - 40:4C=0x3000=12288, more has 76 rows. 80x60x2=9600=0x2580 >>> 132x25 - 40:4C=0x2000=8192, more has 31 rows. 132x25x2=6600=0x19C8 >>> 132x43 - 40:4C=0x3000=12288, more has 46 rows. 132x43x2=11352=0x2C58 >>> 132x60 - 40:4C=0x4000=16384, more has 62 rows. 132x60x2=15840=0x3DE0 >>> >>> >From some informations on net (e.g. here: >>> http://marc.info/?l=freedos-dev&m=106291977718089&w=2 >>> ) it seems as video page size isn't reliable/suitable for no. of rows >>> on screen computing - but I'm not sure, as this may be DOSEMU bug >>> as well. I want to report a bug, but what? DOSEMU, or 'more' command? >> I think it is a bug in dosemu (or both). >> I am currently experimenting with bochs vgabios, and >> it has different page alignment than the one of dosemu. >> Namely: >> >> -#define TEXT_SIZE(co,li) (((co*li*2)+4095)&(~4095)) /* 4000(4096?) text page size */ >> +#define TEXT_SIZE(co,li) (((co*li*2)|0xff)+1) >> >> >> So please try 'vbios_tweaks' branch and see if maybe mode >> is now fine? > Just trying dosemu-1.4.0.8-git647.gf966688.fc19.i686. But when now > is video page size calculated as You mentioned above (i.e. rounded up > to the 256 byte boundary), then still isn't possible take video page > size for no. of screen rows calculating - there may be deviation from > the correct value up to (128 / cols). E.g. when running 'dosemu -t' > in xterm window 40 cols x 48 lines, then Your video page size/ > TEXT_SIZE=4096, from which 'more' calculate 4096 / 40 / 2 = 51.2; > thus it will consider that screen has 51 lines - three more than > in reality. > For 'usual' VBE defined modes is situation better: > > 80x25, VidPgSz= 4096, more has: 25.60== 25 rows, delta=0. > 80x43, VidPgSz= 6912, more has: 43.20== 43 rows, delta=0. > 80x50, VidPgSz= 8192, more has: 51.20== 51 rows, delta=1. > 80x60, VidPgSz= 9728, more has: 60.80== 60 rows, delta=0. > 132x25, VidPgSz= 6656, more has: 25.21== 25 rows, delta=0. > 132x43, VidPgSz=11520, more has: 43.64== 43 rows, delta=0. > 132x50, VidPgSz=13312, more has: 50.42== 50 rows, delta=0. > 132x60, VidPgSz=15872, more has: 60.12== 60 rows, delta=0. > > thus only 80 cols x 50 rows is affected (with 1 line difference) > > Anyhow, FreeDOS 'mode con' in any resolution works fine and display > correct cols and rows numbers (I not know how did it). OK, thanks for testing. So have they looked into your patch? |
From: Frantisek H. <fr...@ha...> - 2014-05-05 07:55:42
|
Stas Sergeev wrote: > 04.05.2014 02:33, Frantisek Hanzlik пишет: >> Hi DOSEMU and FreDOS developers, >> >> FreeDOS 'more' command (tried both 4.2 and 4.3 versions) isn't working >> correctly under DOSEMU when used in screen resolutions other than 80 >> columns x 25 rows. From its code (function GetScreenSize() in more.c) >> it seems as more compute no. of screen rows from BIOS data area, from >> 40h:4Ah (Columns on screen) and 40h:4Ch (Video page size) values, >> using formula: >> ROWS=Video page size / Columns on screen / 2 >> >> which in this case give bad results, as Video page sizes are multiples >> of 4k (number of columns is OK). Here is what Video page size values >> are returned in certain text modes: >> >> 80x25 - 40:4C=0x1000=4096, more has 25 rows. 80x25x2=4000=0xFA0 >> 80x43 - 40:4C=0x2000=8192, more has 51 rows. 80x43x2=6880=0x1AE0 >> 80x50 - 40:4C=0x2000=8192, more has 51 rows. 80x50x2=8000=0x1F40 >> 80x60 - 40:4C=0x3000=12288, more has 76 rows. 80x60x2=9600=0x2580 >> 132x25 - 40:4C=0x2000=8192, more has 31 rows. 132x25x2=6600=0x19C8 >> 132x43 - 40:4C=0x3000=12288, more has 46 rows. 132x43x2=11352=0x2C58 >> 132x60 - 40:4C=0x4000=16384, more has 62 rows. 132x60x2=15840=0x3DE0 >> >> >From some informations on net (e.g. here: >> http://marc.info/?l=freedos-dev&m=106291977718089&w=2 >> ) it seems as video page size isn't reliable/suitable for no. of rows >> on screen computing - but I'm not sure, as this may be DOSEMU bug >> as well. I want to report a bug, but what? DOSEMU, or 'more' command? > I think it is a bug in dosemu (or both). > I am currently experimenting with bochs vgabios, and > it has different page alignment than the one of dosemu. > Namely: > > -#define TEXT_SIZE(co,li) (((co*li*2)+4095)&(~4095)) /* 4000(4096?) text page size */ > +#define TEXT_SIZE(co,li) (((co*li*2)|0xff)+1) > > > So please try 'vbios_tweaks' branch and see if maybe mode > is now fine? Just trying dosemu-1.4.0.8-git647.gf966688.fc19.i686. But when now is video page size calculated as You mentioned above (i.e. rounded up to the 256 byte boundary), then still isn't possible take video page size for no. of screen rows calculating - there may be deviation from the correct value up to (128 / cols). E.g. when running 'dosemu -t' in xterm window 40 cols x 48 lines, then Your video page size/ TEXT_SIZE=4096, from which 'more' calculate 4096 / 40 / 2 = 51.2; thus it will consider that screen has 51 lines - three more than in reality. For 'usual' VBE defined modes is situation better: 80x25, VidPgSz= 4096, more has: 25.60== 25 rows, delta=0. 80x43, VidPgSz= 6912, more has: 43.20== 43 rows, delta=0. 80x50, VidPgSz= 8192, more has: 51.20== 51 rows, delta=1. 80x60, VidPgSz= 9728, more has: 60.80== 60 rows, delta=0. 132x25, VidPgSz= 6656, more has: 25.21== 25 rows, delta=0. 132x43, VidPgSz=11520, more has: 43.64== 43 rows, delta=0. 132x50, VidPgSz=13312, more has: 50.42== 50 rows, delta=0. 132x60, VidPgSz=15872, more has: 60.12== 60 rows, delta=0. thus only 80 cols x 50 rows is affected (with 1 line difference) Anyhow, FreeDOS 'mode con' in any resolution works fine and display correct cols and rows numbers (I not know how did it). Franta Hanzlik |
From: Stas S. <st...@li...> - 2014-05-04 22:02:45
|
04.05.2014 02:33, Frantisek Hanzlik пишет: > Hi DOSEMU and FreDOS developers, > > FreeDOS 'more' command (tried both 4.2 and 4.3 versions) isn't working > correctly under DOSEMU when used in screen resolutions other than 80 > columns x 25 rows. From its code (function GetScreenSize() in more.c) > it seems as more compute no. of screen rows from BIOS data area, from > 40h:4Ah (Columns on screen) and 40h:4Ch (Video page size) values, > using formula: > ROWS=Video page size / Columns on screen / 2 > > which in this case give bad results, as Video page sizes are multiples > of 4k (number of columns is OK). Here is what Video page size values > are returned in certain text modes: > > 80x25 - 40:4C=0x1000=4096, more has 25 rows. 80x25x2=4000=0xFA0 > 80x43 - 40:4C=0x2000=8192, more has 51 rows. 80x43x2=6880=0x1AE0 > 80x50 - 40:4C=0x2000=8192, more has 51 rows. 80x50x2=8000=0x1F40 > 80x60 - 40:4C=0x3000=12288, more has 76 rows. 80x60x2=9600=0x2580 > 132x25 - 40:4C=0x2000=8192, more has 31 rows. 132x25x2=6600=0x19C8 > 132x43 - 40:4C=0x3000=12288, more has 46 rows. 132x43x2=11352=0x2C58 > 132x60 - 40:4C=0x4000=16384, more has 62 rows. 132x60x2=15840=0x3DE0 > > >From some informations on net (e.g. here: > http://marc.info/?l=freedos-dev&m=106291977718089&w=2 > ) it seems as video page size isn't reliable/suitable for no. of rows > on screen computing - but I'm not sure, as this may be DOSEMU bug > as well. I want to report a bug, but what? DOSEMU, or 'more' command? I think it is a bug in dosemu (or both). I am currently experimenting with bochs vgabios, and it has different page alignment than the one of dosemu. Namely: -#define TEXT_SIZE(co,li) (((co*li*2)+4095)&(~4095)) /* 4000(4096?) text page size */ +#define TEXT_SIZE(co,li) (((co*li*2)|0xff)+1) So please try 'vbios_tweaks' branch and see if maybe mode is now fine? |
From: Stas S. <st...@li...> - 2014-05-04 16:39:14
|
Hi. In a hope to get some VGA-related bugs fixed for free, I have imported the vgabios code from here: http://savannah.nongnu.org/projects/vgabios The bugs I was hoping for, are however not being fixed by that, and in fact likely a couple more is added... But I like to have a clean separation between vga emulation and vga bios, so I think this is a good thing to do in general. And it works surprisingly well for the such a quick port, it took only one day to get the things working. Would like to hear what others think. The experimental git branch is called 'vbios_tweaks' |
From: Frantisek H. <fr...@ha...> - 2014-05-03 22:33:28
|
Hi DOSEMU and FreDOS developers, FreeDOS 'more' command (tried both 4.2 and 4.3 versions) isn't working correctly under DOSEMU when used in screen resolutions other than 80 columns x 25 rows. From its code (function GetScreenSize() in more.c) it seems as more compute no. of screen rows from BIOS data area, from 40h:4Ah (Columns on screen) and 40h:4Ch (Video page size) values, using formula: ROWS=Video page size / Columns on screen / 2 which in this case give bad results, as Video page sizes are multiples of 4k (number of columns is OK). Here is what Video page size values are returned in certain text modes: 80x25 - 40:4C=0x1000=4096, more has 25 rows. 80x25x2=4000=0xFA0 80x43 - 40:4C=0x2000=8192, more has 51 rows. 80x43x2=6880=0x1AE0 80x50 - 40:4C=0x2000=8192, more has 51 rows. 80x50x2=8000=0x1F40 80x60 - 40:4C=0x3000=12288, more has 76 rows. 80x60x2=9600=0x2580 132x25 - 40:4C=0x2000=8192, more has 31 rows. 132x25x2=6600=0x19C8 132x43 - 40:4C=0x3000=12288, more has 46 rows. 132x43x2=11352=0x2C58 132x60 - 40:4C=0x4000=16384, more has 62 rows. 132x60x2=15840=0x3DE0 >From some informations on net (e.g. here: http://marc.info/?l=freedos-dev&m=106291977718089&w=2 ) it seems as video page size isn't reliable/suitable for no. of rows on screen computing - but I'm not sure, as this may be DOSEMU bug as well. I want to report a bug, but what? DOSEMU, or 'more' command? Note that 'mode con' properly report no. of cols/rows, and when I in 'more' use 40h:84h (Rows on screen minus one) value (i.e. patch as --- more.c.old 2007-09-23 13:04:00.000000000 +0200 +++ more.c 2014-05-04 00:26:47.948102176 +0200 @@ -84,15 +84,15 @@ void GetScreenSize(void) { unsigned char bios_screencols = *(unsigned char far *)MK_FP(0x40,0x4a); - unsigned short bios_screensize = *(unsigned short far *)MK_FP(0x40,0x4c); - + unsigned char bios_screenrows = *(unsigned char far *)MK_FP(0x40,0x84); + if (bios_screencols != 0) { COLS = bios_screencols; - if (bios_screensize != 0) + if (bios_screenrows != 0) { - LINES= bios_screensize/bios_screencols/2; + LINES= bios_screenrows + 1; } /* printf("BIOS screen size = %u/%u\n",LINES,COLS); */ then more works OK in all modes. Thanks, Franta Hanzlik |
From: Eric A. <e....@jp...> - 2014-04-21 22:14:58
|
Hi Frantisek, DOSEMU people, > Eric, You are using latest (2041?) FreeDOS kernel? dosemu-freedos > package contains older 2036 version. And dosemu-freedos FreeCom My DOSEMU uses 2038, but I am not sure why I picked that version. Let me check http://sourceforge.net/projects/freedos/files/ and the history.txt in there... 2036 is dated 2007-07-21, version 2037 was experimental, 2038 is from 2009-05-16 with some compatibility fixes and FAT and other foolproofing, 2039 from 2009-08-04 has a lot of small changes e.g. in build process, FAT32 init improvement (for USB etc.), code tuning and stripping, includes country.sys of the 2037 unstable branch, various smaller fixes, reduced "fnode" dependency, can cross-compile from Linux. Kernel 2040, 2011-06-21, has relatively small changes: Allow memdisk control of config.sys, 386 register save/restore fix, Watcom C memory layout fix, better error handling, more stack, FAT32/FAT1x decision fix, various. In version 2041, finally (2012-02-07) only has a few small fixes such as ignoring CHS warnings in LBA mode or memdisk versus 8086 / 386. In short, 2036 (dosemu) is really old. 2038 improves stability. 2039 changes a lot, while 2040 and 2041 improve stability again. I think 2041 (maybe 2038) would indeed be a good DOSEMU choice! > version should be '0.84-pre2 XMS_Swap [Aug 28 2006]', but freedos.org > web page (http://www.freedos.org/software/?prog=command) say that this > version is from 2011-07-29 - almost five years newer!? I vaguely remember 0.84pre2 had some hard-to-reproduce issue in which it sometimes stopped running external commands, so special cases *might* still prefer 0.82pl3 instead. The FreeDOS.org list of software has timestamps about when the list was updated. You can see when the software actually was made by looking at the software instead. A collection of FreeCOM command.com is here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/ > And, do You think, that would update the current dosemu freedos to > newest FreeDOS versions had any advantages? That depends on which other tools in the freedos-for-dosemu tarball you would like to update :-) Maybe you even would like to add some, but notice that the tarball aims to provide a relatively basic DOS. A few more tools or drivers might not hurt nevertheless. On 1 to 5 megabytes disk space, you can put enough components to have MS DOS 6 or 7 style feature sets and even (eg htmlhelp) documentation :-) FreeDOS and the software listed on www.freedos.org/software/ are quite disk-space efficient, luckily. RAM usage also is nicely low. Regards, Eric |
From: Stas S. <st...@li...> - 2014-04-21 20:28:23
|
21.04.2014 20:58, Frantisek Hanzlik пишет: > Hello DOSEMU and FreeDOS gurus, > > I'm some time dealing with the idea of writing a program, which should > simplify porting DOS programs which are using some windows supplements > to run on Linux under DOSEMU/FreeDOS. DOS programs, which are still > maintained, are mostly supposed to be run under windows and their > authors often complement them with windows programs, which did some > in DOS problematic tasks (e.g. print to windows printer, sent e-mail, > find free disk space, download something from internet etc.), and > there usually is no support for running these programs under Dosemu+ > DOS. On other hand, many of these supplemental tasks should be simple > solve under Linux too (e.g. print to Linux printer via pcl->ghostscript > filter, send mail via mailx/TB, obtain disk space with shell+df script, > download something with wget etc.). > One such program I'm using and I wonder how to do it, to I can also > use these additional features. My idea is that: > > 1) small DOS program functioning as OS switcher, which I copied as many > times as there are windows programs, under their names. This switcher > will be executed by DOS program instead of the original windows program > - supplement. > > 2) this switcher program will be driven by simple text configuration > file, one line will represent one windows program, and each line will > have three columns: > - program name under which will be this 'switcher' run. > - path to corresponding windows supplement program. > - path to corresponding Linux supplement program/script. When this > path will begin with drive letter, then it will be started as DOS > program, otherwise as Linux program/script. > > 3) this small switcher finds out what name is running, accordingly > looks in the configuration file, and on the basis of whether it > run under DOSEMU or not select proper column - program which should > be started - and run it. Eventual parameters will be simply reused > from those which switcher receive. > > This arrangement (when original DOS program + this switcher will be > on same filesystem, which can be accessed from both Linux and windows) > should allow same functionality when user will work either on Linux or > windows. > > And what I would like like to ask a experts there in lists > - this concept is correct and feasible? > > - In what language should the switch should be programmed? Will be > appropriate to use C and Watcom C for DOS compiler? > > - This switcher should be perhaps as small as possible? But maybe > no - whether it will start Linux or windows program, there will > not be DOS 640 kB memory limitations? Write a simple program that finds out its name and runs a .bat file with the same name. The bat file can then analize your config and run the linux prog via unix.com. |
From: Frantisek H. <fr...@ha...> - 2014-04-21 16:58:38
|
Hello DOSEMU and FreeDOS gurus, I'm some time dealing with the idea of writing a program, which should simplify porting DOS programs which are using some windows supplements to run on Linux under DOSEMU/FreeDOS. DOS programs, which are still maintained, are mostly supposed to be run under windows and their authors often complement them with windows programs, which did some in DOS problematic tasks (e.g. print to windows printer, sent e-mail, find free disk space, download something from internet etc.), and there usually is no support for running these programs under Dosemu+ DOS. On other hand, many of these supplemental tasks should be simple solve under Linux too (e.g. print to Linux printer via pcl->ghostscript filter, send mail via mailx/TB, obtain disk space with shell+df script, download something with wget etc.). One such program I'm using and I wonder how to do it, to I can also use these additional features. My idea is that: 1) small DOS program functioning as OS switcher, which I copied as many times as there are windows programs, under their names. This switcher will be executed by DOS program instead of the original windows program - supplement. 2) this switcher program will be driven by simple text configuration file, one line will represent one windows program, and each line will have three columns: - program name under which will be this 'switcher' run. - path to corresponding windows supplement program. - path to corresponding Linux supplement program/script. When this path will begin with drive letter, then it will be started as DOS program, otherwise as Linux program/script. 3) this small switcher finds out what name is running, accordingly looks in the configuration file, and on the basis of whether it run under DOSEMU or not select proper column - program which should be started - and run it. Eventual parameters will be simply reused from those which switcher receive. This arrangement (when original DOS program + this switcher will be on same filesystem, which can be accessed from both Linux and windows) should allow same functionality when user will work either on Linux or windows. And what I would like like to ask a experts there in lists - this concept is correct and feasible? - In what language should the switch should be programmed? Will be appropriate to use C and Watcom C for DOS compiler? - This switcher should be perhaps as small as possible? But maybe no - whether it will start Linux or windows program, there will not be DOS 640 kB memory limitations? I'm not programmer and it will be tedious job for me, thus I'm asking there, to avoid to do something stupid. Maybe, could someone point to some dos C programming examples? Also, know someone give some example how detect when program is run under DOSEMU or not? Dosemu has isemu.S/detect.h program for it, but it is written in assembler and I can't make head or tail of it :( And I do not understand how the 6+kB resources created 421 B binary, this is some weird magic. Thanks for Your recommendations, excuse my English. Franta Hanzlik |
From: Frantisek H. <fr...@ha...> - 2014-04-21 13:34:50
|
Hi Eric, Eric Auer wrote: > > Hi Frantisek, DOSEMU experts, Aitor, > >> Just when I tried pure autoexec.bat file from latest dosemu-devel, >> I bump to problem with loading display.exe. Line 14 in autoexec.bat >> is 'rem loadhi display con=(vga,437,2)', but when uncommented, then >> give me two errors: >> >> 1) 'FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]' which >> is in dosemu-freedos-1.0-bin.tgz tarball referenced at: >> >> http://prdownloads.sourceforge.net/dosemu/dosemu-freedos-1.0-bin.tgz?download >> >> not know 'loadhi' command; only 'lh' may be used. > > There is a stand-alone tool loadhi.com, the built-in command can > be used either by the name LH or LOADHIGH. Maybe the tarball of > dosemu wanted to use loadhi to not depend on command.com version. You are right, I found loadhi.com somewhere - but it was version from 1995 year, thus maybe this was existed before this function was implemented in FreeCom. Anyway, in official dosemu-freedos tarball this utility isn't present. And FreeCom know both 'loadhigh' and 'lh'. >> 2) display-0.13b report error: >> >> FreeDOS DISPLAY ver. 0.13b >> Syntax error (006) Unknown hardware device name >> >> when I retain its parameters. But when I use 'ega' instead of 'vga', >> then all is fine. I not know, when it is display... > > That might be a bug in display: Reading the sources of an older > version, VGA and EGA should both be accepted. See also my reply > to your FreeDOS mailing list question: You can say EGA here, it > works the same for fonts. Only the amount of graphics memory and > the set of font sizes differ. But at least for older versions of > DISPLAY, the setting "EGA" meant to autodetect exactly those :-) > >> ... documentation ... 'vga' is allowed) or dosemu problem (e.g. >> it emulate only EGA card and not VGA). > > No, EGA and VGA are treated pretty much the same by DISPLAY, it > only treats CGA in a different way. Also, DOSEMU supports VGA > quite well, also for loadable fonts as far as I remember ;-) In > any case, that error message is about option syntax. You would > get a different error if no EGA/VGA card was found by DISPLAY. > >> According this, and as this autoexec.bat file has in its head that >> it should be for DOSEMU + FreeDOS, maybe this change should be better: >> >> --- dist/autoexec.bat.old 2014-04-21 00:38:46.273663431 +0200 >> +++ dist/autoexec.bat 2014-04-21 00:50:12.053661641 +0200 >> @@ -11,7 +11,7 @@ >> lredir d: linux\fs%DOSDRIVE_D% >> :nodrived >> rem uncomment to load another bitmap font >> -rem loadhi display con=(vga,437,2) >> +rem lh display con=(ega,437,2) > > I would even say (EGA,,1) to use less RAM and be less strict. > >> rem mode con codepage prepare=((850) z:\cpi\ega.cpx) >> rem mode con codepage select 850 >> rem chcp 850 > > Not sure how relevant the last CHCP step is, it probably is > duplicating the explicit setting by MODE in some aspects... > >> and also in freecom help file: >> >> --- dosemu/freedos/help/index.en.old 2003-09-28 05:55:27.000000000 +0200 >> +++ dosemu/freedos/help/index.en 2014-04-21 01:27:35.012479480 +0200 >> @@ -16,7 +16,7 @@ >> help ... you just called this one >> join mount a drive letter into a directory >> lib librarian for OBJ files, creating a LIB file >> -loadhi loads a program into the upper memory >> +lh loads a program into the upper memory > ? > Not sure where this file comes from. Note that you can type > "?" as a command to get a list of commands and e.g. LH /? to > get help about LH and so on. The HTML based HELP command has > a page about LH aka LOADHIGH but none about LOADHI... > > I guess INDEX.EN is a file provided by DOSEMU, given that it > also explains the DOSEMU-specific LREDIR. This ('/usr/share/dosemu/drive_z/help/index.en', which should be 'Z:\help/index.en' in DOS) is, it seems, printed by 'help' command (Z:\bin\help.exe). This file is maybe somehow customized by dosemu team. >> mem displays the amount of DOS memory used >> more displays a text file one screen at a time >> nansi nansi.sys, an enhanced MS-DOS console driver >> @@ -80,9 +80,9 @@ >> vgaoff only for 'root'!! switch vga mode off (when on console) >> vgaon only for 'root'!! switch on console vga graphics mode >> NOTE: vgaoff/on may be dangerous on console, but >> - do nothing important on X. >> - >> + do nothing important on X. >> lredir set/display redirection of a Linux directory to a DOS drive >> + or set redirection to network virtual printer. >> unix take over Linux ENV variables, execute DOS command from >> a given ENV variable, execute Linux commands ... >> dosdbg set/display debug(Log) features/flags >> >> One thing which I not know: some FreeDOS utilities have newer version now >> (compared with those in dosemu-freedos-1.0-bin.tgz), but is possible use >> them with dosemu? >> Maybe Bart patched some key components (FreeDOS kernel, FreeCOMM etc.) >> and newer versions will not be functional? Knows someone? > > Maybe the problem is just that the tarball of FreeDOS things for DOSEMU > has not been updated after FreeDOS 1.0 got released: It would surprise > me if anything in this tarball is a special DOSEMU version. DOSEMU can > run random software for DOS quite well. However, there are some tools > which ONLY work in DOSEMU, such as for example LREDIR. If those are a > part of dosemu-freedos-1.0-bin.tgz, then they are probably taken from > a package of things-for-DOSEMU that may have been updated separately. > > Another example are HIMEM and EMM386: Instead of using those for real > hardware, you can and should use the "magic" DOSEMU versions where the > emulator provides most of the functionality itself. That way, it needs > less (slow) hardware simulation to provide the same experience. > > My current DOSEMU installation contains the following special DOSEMU > DOS tools and drivers: cdrom, ems, emufs, aspi and dumpconf.sys and > isemu, fossil, mgarrot and generic.com: The latter is also symlinked > to xmode, vgaon, vgaoff, unix, ugetcwd, uchdir, system, speed, lredir, > exitemu, emumouse, eject, ecpuon, ecpuoff, dpmi, dosdbg, cmdline, > booton, bootoff and blaster.com as calling generic.com by different > filenames lets you invoke different "magic" things, often for setup. > Interestingly, those files are all less than 1 kilobyte "big" each. > They all work only in (any, not just Free-) DOS and only in DOSEMU. > > Regards, Eric My questions was mainly about FreeDOS kernel.sys and FreeCom - what would be surprising that, when it can exploit benefits of free software, FreeDOS together with DOSEMU, will be able do some features over other closed-source DOSes? Eric, You are using latest (2041?) FreeDOS kernel? dosemu-freedos package contains older 2036 version. And dosemu-freedos FreeCom version should be '0.84-pre2 XMS_Swap [Aug 28 2006]', but freedos.org web page (http://www.freedos.org/software/?prog=command) say that this version is from 2011-07-29 - almost five years newer!? And, do You think, that would update the current dosemu freedos to newest FreeDOS versions had any advantages? Thanks, Franta Hanzlik |
From: Frantisek H. <fr...@ha...> - 2014-04-21 08:58:31
|
Edward Mendelson wrote: > I don't have a Linux system running at the moment, but I was able to get > a 132x50 DOSEMU through the methods described here: > > http://www.columbia.edu/~em36/wpdos/linux.html#screensize > > This does not use a VESA mode. Instead, it simply displays the default > text font in a larger window, which I think is preferable because far > easier to read. > > Edward Mendelson Hi Edward, thanks for link. I use this ('dosemu -t' in xterm window) also when I'm working under X Window, but it isn't possible or useful use this always - thus 'native' dosemu mode would be better. I kind of hoped (when I saw in dosemu vesabios.*, vgaemu*, vesa.*, vbe.* etc. sources indices that some VBE extensions are supported) that 0x10B mode 132x50 support will in ideal case meant only something as e.g. fill one row of src/env/video/vgaemu_modelist.h table etc. Yes, my imaginations are maybe foolish, but... Thanks, Franta Hanzlik |