Re: [Freedos-devel] Back at it with DOG

[Eric Auer via Freedos-devel]

Hi and welcome back, Wolf :-)


I used to map a virtual drive to a folder on Linux - but like you
found, I sometimes had problems with that (not all the time, just
sometimes) so I stopped doing that. When I need to get access to my
virtual drive, I use guestmount from the libguestfs package to "mount"
the virtual disk from Linux:

$ mkdir mystuff
$ guestmount -a mystuff.qcow2 -m /dev/sda1 mystuff
...
$ guestunmount mystuff



Ah so you do less frequent copying from the DOS image to your linux system
for things like git commit?
I'm also going to try EtherDFS and see if that can solve it so that I can
edit code on linux and then build and test in a QEMU box which is
constantly running. :)


Time for the usual advertisement: DOSEMU2 makes those things very
easy by magically letting you use Linux directories of your choice
as drives for DOS :-)

Cheers, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] zoo just needs packaging

[Eric Auer via Freedos-devel]

Hi!

To get the discussion a bit more productive again:

https://www.bttr-software.de/forum/board_entry.php?id=21046=0=time=0

is the original thread and apparently RayeR has used Borland C
to compile a fixed binary which Fritz has received and tested?

So the ONLY thing missing seems to be putting everything into
a ZIP (yeah, no .ZOO) file in the usual FreeDOS structure, as
has happened with my RUNTIME recently thanks to some support,
help and contributions from Vacek and Jerome :-)

The patch fixing ZOO involves changing "int" to "unsigned long"
in 4 lines of the ZOO source code, spread over 3 different files,
provided by RINGDING, who also offered a Turbo C++ build here:

https://drive.google.com/file/d/1XRexqJvbKvNwRNPlAhvIEF1Toee_Cbtt/view?usp=sharing

Apparently people somehow failed to come to a conclusion which
version of ZOO to package under which license in January 2024.

Yet, for me, that does NOT sound like a reason to drop the whole
package from our collection. Even if "nobody" uses ZOO :-p I mean
barely anybody uses RUNTIME, either. But it is nice to have :-)

Regards, Eric

PS: There are some newer bug reports from Paul Dufresne on gitlab,
regarding packages such as upx, label, rcal and wing. Any news here?



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] zoo

[Eric Auer via Freedos-devel]

Hi!

I ran one more test with zoo. It runs with FAT16 998 MB but not with 
FAT16 1025 MB.


Did you use the original version for that test?

Or the one already having the fix from the forum?

The old zipper "zoo" has a built-in bug that prevents it to expand 
compressed files on FAT32 system.



See:
https://www.bttr-software.de/forum/board_entry.php?id=21046=2=all=last_answer=DESC 



There was already a solution at this forum.
Question: Does it make sense to update it for FDT240x?





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Ancient Windows compatibility notes

[Eric Auer via Freedos-devel]

Hi! As Jim prefers such things to be on-list,
here are some 2004 (and one 2006) bits from
my archive regarding Windows compatibility,
in context of the WfW 3.11 compatibility howto
advertised on BTTR and here recently. Maybe
some of you would like to have a look to see
whether anything is still missing? I doubt it
and it is quite likely that my notes are not
accurate and/or outdated, but who knows? Thank
you and enjoy the old DOS thought snippets :-)

Cheers, Eric

PS: Sorry about mailing an attachment!


windows-freedos-notes-2004.7z
Description: application/7z-compressed
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Eric Auer via Freedos-devel]

Hi!

Well, what is wrong with

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/fdisk.html

or alternatively

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/xfdisk.html

or even

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/aefdisk.html

to begin with?

FreeDOS fdisk seems to be quite okay including translations to
Turkish, German, Spanish, French and Swedish. It even mimicks
part of the user-unfriendliness of MS FDISK, yet still adding
features which Microsoft did not offer :-D

Cheers, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] OT: Creating new threads

[Eric Auer via Freedos-devel]

Hi Willi,

My main problem is, that I can answer via mail, but I have absolutely 
forgotten how to create a new thread. ...

Simply changing the "Subject" seems not to be the solution.


The trick is to send a completely new mail to
freedos-devel@lists.sourceforge.net - this will
create a new thread. If you only reply to some
existing thread, mail software can recognize it
as part of the old thread, even if you change
the subject.

Regards, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] freedos runtime and terminal updates and alternatives

[Eric Auer via Freedos-devel]

Hi!

Willi has asked Jerome and me whether RUNTIME and TERMINAL
in the auersoft.eu versions were real updates or just tests.

Jerome asked him to ask on the LIST, so I answer HERE ;-)

*Runtime*

Jim's version is a small C program, 120 lines, using catgets
for messages which can be translated in different languages.
The binary is a 22kB EXE (31kB without UPX). There were text
files with EN, RU, DE, HU and LV translations, I believe?

My version is a small ASM program, made with NASM. It has
a main file, circa 450 lines, and a language include file,
circa 150 lines, which at the moment contains EN, DE, NL,
PT, ES, FR, TR, IT, PL and RU messages :-) To add languages,
you have to build a new binary. Not very hard, but harder
than just editing a text file which can be used by CATGETS.
The binary is a 2kB COM (3kB without UPX).

Note that texts in all 10 language are INCLUDED in the 2kB
COM file of my tiny version. No separate NLS files there.

As a task left as an exercise for the user, one could port
the C version to Tom's small KITTEN alternative to CATGETS.

My preferred option would be to add HU and LV translations
to my small RUNTIME and use that instead of the big one ;-)

*Terminal*

Regarding TERMINAL, the distro contains version 3.2a 2015-05-16.
The files in the ZIP have timestamps between 2001 and 2005 for
source code and 2021-2022 for translations.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/terminal.html

The version mentioned by Willi, terminal-2007jun20, contains
2007 changes to terminal.asm, term-irq.asm and term-data.asm,
with the following minimalist changelog:

"update in V3.3 6/2007: added a forgotten in al,dx term-irq.asm:217"

The change in terminal.asm are just adding the above as a comment.
The change in term-irq.asm is just adding that "in al,dx".
The change in term-data.asm is just changing version and date in
the msg_hello string. Note that the sources have LONG FILE NAMES
which somehow got lost in the download available on Ibiblio!

The version on ibiblio comes with more metadata in APPINFO: The
LSM file and small TERMINAL.xyz files in different languages xyz,
for example the French APPINFO/TERMINAL.FR file says:

Begin3
Language:FR, 850
Title:   terminal
Description: Un petit terminal vt100/ansi pour tous les PC
Keywords:terminal, rs-232, vt100
End

I guess it would be nice if the ibiblio version got updated with
my 2007 version, but preserving the nice added ibiblio metadata.
Please take care to preserve source LFN and timestamps, though.

Thank you :-)

Cheers, Eric



[...]

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/runtime/
 there is a version from Eric Auer from 03sep2012
 FDT2404 uses ver. 2.1 from Jim Hall, 2002
Is it an update? You should bring it up on the mailing list or ask Eric if it 
should be updated.

terminal https://www.auersoft.eu/soft/  terminal-2007jun20 (3.3)
  FDT2404 uses 3.2a
Like RUNTIME, these versions predate me performing package updates. So, I don't 
know
if those are updates, experiments or just different. You should ask Eric.

[...]




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[Eric Auer via Freedos-devel]

Hi!

I have no life - I can devote the time and energy to it, just don't have 
the brainpower I'd like to think I have.


I hope that will get better :-o

Eric





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] MBR boot failure + diagnosis on a PhoenixBIOS 4.0 Release 6.0 machine

[Eric Auer via Freedos-devel]

Hi Bernd,


/LOADMBR restores the whole sector. Does anyone think this is a major issue?


In that case, I think loadmbr should never be used except
when there was a previous corresponding savembr. Because
using loadmbr in another way results in deleting the whole
partition table and/or installing a new partition scheme
which will probably not fit to the size of the target disk.

Similarily, cleanmbr should never be used without plenty
of warning to the user and giving the user at least two
chances to select a less destructive option.

If the context is letting the installer work on a virtual
computer with a fresh disk image, where you expect nothing
of value could get lost, then I suggest creating a tool
to detect whether the MBR and partition table already WERE
empty in that disk image instead of automatically emptying
them. Or just offering a pre-installed disk image download.

Greetings, Eric



 The documented commands are as follows (via FDISK /?):


MBR (Master Boot Record) management:
/CLEARMBR Deletes all partitions and boot code
/LOADMBR Loads part. table and code from "boot.mbr" into MBR
/SAVEMBR Saves partition table and code into file "boot.mbr"

MBR code modifications leaving partitions intact:
/IPL Installs the standard boot code into MBR 
  ...same as /MBR and /CMBR for compatibility
/LOADIPL Writes 440 code bytes from "boot.mbr" into MBR

Greetings, Bernd






___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Windows for Workgroups howto

[Eric Auer via Freedos-devel]

Hi!

Hidden in the "Tyrian 2000 in DOS with sound on PCIe only machines?"
thread on BTTR which also contained the VSBHDA (soundblaster emulation
for HDA machines, Japheth's variant) announcement, I found this link:

https://github.com/pufengdu/RetroFuns/blob/main/WFWG/FDWFWG.md

it explains how to run Windows for Workgroups 3.11 with FreeDOS.
This could be a lot easier after updating our distro.

ECM has compiled our kernel with -DWIN31SUPPORT here:

https://pushbx.org/ecm/test/20230805.2/kwin31.zip

You also need ECM's improved SHARE compile:

https://pushbx.org/ecm/download/fdshare.zip

This already got some stackexchange coverage in 2023 here:

https://retrocomputing.stackexchange.com/questions/27480/how-to-use-start-windows-3-11-with-freedos

Now you can install Windows, but you have to select "return to DOS"
at the end of the install to modify settings before running Windows:

 - Use the Microsoft versions of HIMEM and EMM386 and SMARTDRV
   (bundled with Windows, alternatively from MIT-released MSDOS 4?)
   so update your config and autoexec accordingly

 - Edit SYSTEM.INI to comment out 3 drivers in the [386enh] block:

; Device=ifsmgr.286
; Device=vcache.386
; Device=vshare.386

 - In the same block, activate more compatible InDOS tracking:

InDOSPolling=True

Now Windows for Workgroups 3.11 should run with FreeDOS, even
on FAT32 drives, since you have deactivated some 386 protected
mode, FreeDOS-incompatible filesystem / cache / share drivers.

Do not enable 32BFA or 32BDA. Use only temporary swap files.

For proper Alt-Tab/Alt-Enter handling, use 4DOS instead of
FreeCOM, or press ENTER after each Alt-... sequence if you
want to stick to FreeCOM.

The howto described above also links to:

https://danielectra.github.io/blog/windows-31-on-freedos

this mentions that the relevant FreeDOS kernel patch dates back
to 2021-08-19, so it is a pity that this has still not become a
part of our standard distro. This 2022 howto also mentions that
the whole FreeDOS installer hangs, so the author had to install
FreeDOS in a VM and then copy the result to the real computer.

If you only want to use Windows 3.1, not Windows for Workgroups,
you can use the free open source HIMEMX :-) You do need that
InDOSPolling=True line, but you do not need to disable things.
SVGA 800x600 256 color drivers should work on common hardware.

Here is what Jeremy and ECM patched in the kernel in 2021:

https://github.com/FDOS/kernel/commit/9186e6c5ed1ab58bf1dc0497bacc352d3d758703

That improves InDOS and critical section handling, such as
int 2a.8001/8101 calls, indos flag updates, and adds
int 2f.13/16xx/46 support and int 13/19 vector tracking,
as well as a fix for int 2f.4a33 to clear BX now, etc.

Regards, Eric



PS: Another possibly interesting topic mentioned on BTTR is:

https://github.com/pufengdu/IO8EMMOK

which lets you use EMM386 with MS DOS 8 to run Windows 3.x on
8042 A20 style hardware UNLESS you have done the competing

https://msfn.org/board/topic/183250-how-to-disable-the-built-in-xms-driver-in-windows-mes-iosys

and only AFTER you have replaced, twice, 66 c7 46 49 ff ff by
6a ff 8f 46 49 90 in win386.exe for unknown reasons. That
io8emmok tool manipulates XMS, memory sizing and A20 things.

It also comes with a loader which performs an in-memory patch
to MS DOS in the HMA to fix compatibility, which changes:

cmp di,0x400 => change to 0x300
jnc +6
mov si,0x4
jmp -0x205
push ax
xor al,al
xchg al,[0xf5c]
pop ax
jz -0x12 => replace by NOPs

The BTTR user uses the following MS DOS 8, Win3.x config:

device=io8emmok.sys
device=emm386.exe noems
install=xmsres.exe 512
install=w3xstart.com

XMSRES is a tool by Japheth to limit visible XMS, here to
512 MB, because Windows would need config tricks to avoid
overflows in virtual memory / swap processing otherwise :-p

See also https://jeffpar.github.io/kbarchive/kb/084/Q84388/

and https://kb.iu.edu/d/abpe

You want to set PageOverCommit=1 or 2, not the default of 4,
in system.ini to make Win3 work with up to 1 GB of RAM. Our
HIMEM also has a /MAX=... option to globally limit XMS size.



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[Eric Auer via Freedos-devel]

Hi Bernd,


Microsoft and IBM released the source code of MS-DOS 4.0
under MIT license [1]. To me, it looks fairly complete.

Greetings, Bernd

[1] https://github.com/microsoft/MS-DOS/tree/main/v4.0


As mentioned by DOSEMU2 people, this is a somewhat exotic,
but interesting MS DOS 4.00, not the once widespread 4.01:

https://cloudblogs.microsoft.com/opensource/2024/04/25/open-sourcing-ms-dos-4-0/

Cheers, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] country sys update missing?

[Eric Auer via Freedos-devel]

Hi!

Willi and Laaca noticed that the country sys settings for Germany
have a flaw, but apparently Andrew, Jeremy and RR already updated

https://github.com/FDOS/country/commits/master/country.asm

so I guess this is a simple fix which can be implemented by
updating the relevant FreeDOS package based on current GIT?

Thanks :-)




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] List of app links and versions

[Eric Auer via Freedos-devel]

Hi!

Willi has made a list of links and version numbers of apps:


https://www.bootablecd.de/FreeDOS-tools-hyperlinks.zip
 
There are two new updates:

doszip 2.66 (fixes a bug in search)
ldebug 8


This can be useful to spot updates for our distro and
for adding some extra details and links to our LSM :-)

Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Fwd: lspci (pciutils) for freedos

[Eric Auer via Freedos-devel]

Hi!

LSPCI relies on a rather large list of known PCI ID,
which is why I made PCISLEEP long ago: It just has
a small list of known vendors and types, to keep the
installation small :-) It also experiments with PCI
based standby and suspend modes, including VGA ones.

But of course, having a full LSPCI for DOS would not
hurt either, for more detailed information :-)

Eric

PS: PCISLEEP is written in Assembly language. For a
DOS version of LSPCI, I suggest using BIOS calls or
raw I/O and keeping the rest in original LSPCI style.




Hi Pali,

I will forward your message regarding lspci to the FreeDOS mailinglist. Thanks 
for sharing this information!

Greetings, Bernd


Anfang der weitergeleiteten Nachricht:

Von: Pali Rohár 
Betreff: lspci (pciutils) for freedos
Datum: 9. März 2024 um 12:49:53 MEZ
An: Bernd Boeckmann 

Hello,

I read the freedos wiki page contribute
https://freedos.sourceforge.io/wiki/index.php/Contribute

and I would like to let you know that the "lspci" tool known from the
linux which lists and prints information about all PCI devices connected
in the system, works also on freedos and the last version now has
pre-compiled binaries in the pciutils project page. They are in windows
download section, but are compiled with DJGPP toolchain.
http://mj.ucw.cz/sw/pciutils/

I saw more questions from users if there is a lspci-like tool for
freedos to list PCI devices, so I think that the original lspci can be
useful for freedos. Would you consider including it into distribution CD?
Note that pciutils library is used by flashrom which is already present.

Pali






___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] comcom32 shell

[Eric Auer via Freedos-devel]

Hi again!


It seems the djgpp-compiled 32-bit version of the comcom shell
of dosemu2 will be abandoned, moving to a 64-bit only version.


Stas found out that comcom64 is compatible with 32-bit
toolchains, so dosemu2 could keep an eye on that to keep
comcom64 compatible with 32-bit builds for plain DOS use.
Even a continous integration automated CI testing eye ;-)

So instead of adopting comcom32, joining comcom64 work

https://github.com/stsp/comcom64 (maybe soon in dosemu2 GIT?)

and then compiling a 32-bit DOS version with DJGPP can
be an alternative way to get another nice shell for DOS.


Maybe somebody wants to pick up comcom32 for use in plain DOS:

https://github.com/dosemu2/comcom32


There are some comcom32 issues and wishes at the moment:

https://github.com/dosemu2/comcom32/issues

 - CD changes drive
 - COPY does not support concatenation mode
 - MORE only half-works, see issue #17

 - some build issues
 - build instructions for README

 - cannot be used as PC-DOS SHELL=... because of empty env
 - no int 2f.aexx installable command API
 - no tab completion support yet

 - batch file /Y mode would be interesting
 - might be interesting to add mouse support
 - might be interesting to add a built-in MEM


Note that this shell requires CWSDPMI exe in the same directory
as the comcom binary, for example the root directory, if you
want to use it as the primary shell. According to the source
code comments, TIME, DATE, CHOICE, MORE and PAUSE still need
work. For example MORE just does TYPE as far as I can tell.

Regards, Eric





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] comcom32 shell

[Eric Auer via Freedos-devel]

Hi!

It seems the djgpp-compiled 32-bit version of the comcom shell
of dosemu2 will be abandoned, moving to a 64-bit only version.

Maybe somebody wants to pick up comcom32 for use in plain DOS:

https://github.com/dosemu2/comcom32

Note that this shell requires CWSDPMI exe in the same directory
as the comcom binary, for example the root directory, if you
want to use it as the primary shell. According to the source
code comments, TIME, DATE, CHOICE, MORE and PAUSE still need
work. For example MORE just does TYPE as far as I can tell.

Regards, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NewDOS source code has been published!

[Eric Auer via Freedos-devel]

Hi Willi,

I will wait some days to see if there are other questions or proposals 
referring to NewDOS and then send André Olejko a list with everything at 
one time in german...


He explicitly asked to NOT be bothered with such things. So I suggest
that we just collect the questions and proposals ourselves and then,
if necessary, get some publicity to find volunteers to implement them.

Because I know ONE person who will NOT be among those volunteers ;-)

Or maybe people simply enjoy the fact that they can manually READ the
sources for those tools which already were available as freeware binary.

Maybe there is no need whatsoever to change or compile anything, yet?

One of my questions will be if the source code of asm86 can/will be 
published.


That has VERY low priority. Plenty of FreeDOS apps need closed source
or even non-free compilers. If anybody ever has an issue with that for
NewDOS, we can still go the NoMySo way and (semi-automatically) port
the sources to any free and open assembler and C compiler out there.

If the author makes Asm86 open source at some point, fine, but I would
recommend to not even ask for that right now. Maybe not even this YEAR.

Another important detail: No matter which compilers you use, you cannot
compile NewDOS out of the box right now! You will first have to take a
deep breath, THINK which toolchain you need, configure it properly and
come up with a nice build script or makefile. NONE of those is included
in the sources, which were released AS-IS, rough and raw, but valuable.

So before you ask for a license change to the assembler, let us FIRST
see who and WHEN will undertake re-compiling this nice software. Either
for the challenge or because they MAY have specific ideas for patches.

All of this will take TIME. Not just some days. More likely months.

Please compare this to the situation in 2020 when Steve and TK felt
like taking the challenge to make it possible to actually COMPILE the
GW BASIC sources released in what it turned out to be incomplete AS-IS
state by Microsoft. Nobody would have asked Microsoft to FIRST make
all involved compilers open source at that time. And nobody has asked
Microsoft to publish the missing source code snippets.

Because the situation was pretty much the same as now: The authors
had looked into their archives, FOUND a mostly complete copy of the
sources and said: We have this code GIFT, you MIGHT enjoy it, but we
cannot and will not help you if it is not good enough for you! ;-)

I personally think that André Olejko did a great job, one single man 
created "a half OS"!


I totally agree that this is a cool collection of tools and it is
great that the author made it free first and even open source now!

We cannot and should not expect anything else. Thanks for the ZIPs!

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop

[Eric Auer via Freedos-devel]

Hi Jim,


http://www.bttr-software.de/forum/board_entry.php?id=21061 ...


By now, the BTTR thread has figured out that the bug was
in the Xi8088 BIOS, not in XT-IDE: When calling unsupported
(bei neither XT-IDE nor the main BIOS) disk functions, the
main BIOS trashed the int10 vector. A fixed update exists,
as far as I understand the ongoing discussion :-)

Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Eric Auer via Freedos-devel]

I made recompiling Edlin easy for non-programmers,
so that shouldn't be a problem. You don't have to
know a lick of C to recompile it.


One would still need the toolchain, so it would
be great if there could be somebody who already
has it (and does know C, just in case) who would
volunteer as the "send me your NLS updates for
EDLIN and I will make sure an updated EDLIN zip
will get published" person. Or, as said, a CI way.

Eric

PS: As mentioned on BTTR in the Book8088 compat thread
(which found out that SYS CONFIG GLOBALENABLELBASUPPORT=0
can work around some crash in XT-IDE BIOS!) even seemingly
easy to use compiles fail in *unexpected* ways, e.g. OW
2.0 compiles kernels in Linux, but only 1.9 does in DOS?




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Eric Auer via Freedos-devel]

Hi!


Willi Spiegl said in the meeting that there is no NLS in Edlin. I beg to differ!


As with the HTMLHELP versus AMB issue, the problem, as far as
I have understood Willi, is the lack of a process, possibly
an automated pipeline, which will take updated translations
and spread them to the right places. As a non-programmer, he
would not recompile EDLIN to submit updated translations, so
we have to figure out whom and how to give the files so the
updates get published to the right, easy to use places :-)

Eric

PS: The same probably applies to CTMOUSE and similar tools
with compile time translations. Could be put into continuous
integration pipelines, but then updates are rather rare here.




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop

[Eric Auer via Freedos-devel]

Hi Jim,


I'm glad you're bringing this conversation back to freedos-devel ..
because this is a good place to discuss FreeDOS things.


In related news, the dosemu2 people also find the problem interesting.

Their discussion mentions that FDPP, a port of the FreeDOS kernel,

https://github.com/dosemu2/fdpp

fixes plenty of issues listed in our kernel bug lists. So maybe
somebody feels like backporting those to FreeDOS. However, as far
as I remember, the diff is huge, nothing easily cherry-picked.

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Cleaning up FDAUTO

[Eric Auer via Freedos-devel]

Hi guys, thanks for cleaning up autoexec!


REM - streamlined the network test (user adds their own stuff anyway).


I hope they add it at a place where it actually gets to run :-)


set PATH=%DOSDIR%\BIN
if exist %DOSDIR%\LINKS\NUL set PATH=%path%;%DOSDIR%\LINKS


A special test just for one app? I would prefer if LINKS came
with a batch wrapper which gets placed in BIN, then PATH does
not have to dynamically add the directory of LINKS.

If LINKS means such wrappers instead of the browser LINKS, then
I suggest to just put all batch wrappers in the BIN directory.


set TZ=UTC


Personally, I prefer RTC having local time. Add a comment here?


alias reboot=fdapm warmboot
alias reset=fdisk /reboot


You can also reboot with FDAPM COLDBOOT or FDAPM WARMBOOT.


:SUPPORT286

fdapm APMDOS


This sort of implies that HLT saves no power on 8086?
On the other hand, 8086 are low on RAM, so it probably
is best to load as few drivers as possible there, yes.

In a related thought, we should pick a KSSF swapping
or otherwise non-XMS-swapping freecom command.com in
ALL cases where no XMS driver is loaded. Be it because
the CPU is too old, be it because the user choses some
boot menu option without XMS drivers deliberately.


ctmouse


You can compile CuteMouse for 8086, but that uses slightly
more RAM. In addition, buggy versions exist where the 8086
compile actually requires a newer CPU. Either way, as we
are talking of mice and men, you may want to do this in an
"either load this or load that ctmouse version" way instead
of and "either load ctmouse or do not load it" way :-)


:SUPPORT386

if "%CONFIG%"=="4" goto SUPPORT386LOW

lh fdapm APMDOS
REM lh share


In which way is SHARE 386 specific?


:SUPPORT386LOW

fdapm APMDOS
ctmouse


So SHARE only gets loaded at all if loaded high?


if exist %DOSDIR%\bin\cdrom.bat call %DOSDIR%\bin\cdrom.bat


Do we also have CD-ROM and DVD or BD drivers for 8086 or 286?


if exist %DOSDIR%\bin\fdnet.bat call %DOSDIR%\bin\fdnet.bat start
REM - add your own networking commands here: (if any)


I assume that batch autodetects networking at each boot?
I believe people may just manually edit autoexec anyway.


if exist %DOSDIR%\bin\fdassist.bat call %DOSDIR%\bin\fdassist.bat
if exist %DOSDIR%\bin\cdrom.bat call %DOSDIR%\bin\cdrom.bat display
if exist %DOSDIR%\bin\welcome.bat call %DOSDIR%\bin\welcome.bat


For my taste, the boot process is split into too many batch files.


REM nlsfunc %DOSDIR%\BIN\COUNTRY.SYS
REM display CON=(EGA,858,2)
REM mode CON CP PREP=((858) %DOSDIR%\CPI\EGA.CPX)
REM keyb US,858,%DOSDIR%\bin\keyboard.sys
REM chcp 858
REM mkeyb UK


You probably want suggest to load all of those earlier.

If people just remove the REM, the font and keyboard
drivers would get loaded quite late.

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop

[Eric Auer via Freedos-devel]

Hi! As you may have read, some company has created an eeepc sized PC-XT
laptop called Book8088. It ships with MS DOS on a CF card. Bocke got an
EDR-DOS kernel and SvarDOS apps to work on it, too, but FreeDOS kernels
crash. SvarDOS is a FreeDOS based floppy distro - http://svardos.org/
which is maintained by Mateusz. It also has an active forum :-)

Given that others must have used FreeDOS on 8086 or 8088 with 640k RAM
before, the assumption is that something goes wrong in/after partition
enumeration. Maybe some unsupported BIOS functionality is called or
there is an issue with the geometry?

Now it would be useful to have a known good 8086 compatible kernel which
has some debug messages enabled. Which FreeDOS kernel binary would you
recommend for that? Or maybe somebody wants to join the thread on BTTR
and work on the kernel interactively?

Modified BIOS versions for the Book8088 already exist, too. Also, it
turned out (according to VOGONS or VCFED) that the VGA BIOS has some
issue with Windows and other software. An update exists, but apparently
it cannot be flashed via ICP in-circuit, so one would have to desolder
the EEPROM to update the VGA BIOS to use the full resolution and colors.

https://www.bttr-software.de/forum/board_entry.php?=21061_page=1=ASC=0=all=time=DESC

shows photos telling us that one of the tested CF cards has geometry
1006x16x63 with 1014048 LBA sectors, but there is no int 13.48 in the
BIOS, only int 13.8 support in the add-on XTIDE BIOS r625.

A FreeDOS 2043 kernel built 2021-05-13 with FAT32 support built with
Watcom C (hopefully an 8086 compatible build!) shows the version and
copyright messages and lists the C: partition, but then hangs:

C: HD1, Pri[1], CHS=0-1-1, start=0 MB, size=480 MB

Regards, Eric


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2402

[Eric Auer via Freedos-devel]

Hi Jerome,


For these: They are version updates.


2024-02-01 05:49:48 upx (shidel): updated to 4.2.2
2024-02-01 05:44:35 liquiwar (shidel): updated to 5.6.4
2024-02-01 05:38:55 testdisk (shidel): updated to 7.2
2024-02-01 05:33:34 fbc_help (shidel): updated to 1.10.1
2024-02-01 05:17:54 sleep (shidel): updated to 1.1
2024-02-01 05:17:06 fbc (shidel): updated to 1.10.1
2024-01-31 18:00:28 lzop (shidel): updated to 1.04
2024-01-31 17:51:24 lzip (shidel): updated to LZIP 1.20 and LZIPRECOVER 1.21



As for what specifically changed in each of those version updates, I couldn’t 
say.


Exactly that would have been my specific question. Who could answer it?


You would need to check the change log (if any) that is included in the 
respective package.


Yet you have added those updates, so I would have expected you to know?

Can you provide links to the changelogs so somebody who is less
into programming but still wants to help could summarize them
for this mailing list?

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2402

[Eric Auer via Freedos-devel]

Hi Jerome, thanks for the updates! :-)


The FreeDOS Interim Test Build T2402 for February is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Changes since T2401:


What specifically has changed in those packages?


2024-02-01 05:49:48 upx (shidel): updated to 4.2.2
2024-02-01 05:44:35 liquiwar (shidel): updated to 5.6.4
2024-02-01 05:38:55 testdisk (shidel): updated to 7.2
2024-02-01 05:33:34 fbc_help (shidel): updated to 1.10.1
2024-02-01 05:17:54 sleep (shidel): updated to 1.1
2024-02-01 05:17:06 fbc (shidel): updated to 1.10.1
2024-01-31 18:00:28 lzop (shidel): updated to 1.04
2024-01-31 17:51:24 lzip (shidel): updated to LZIP 1.20 and LZIPRECOVER 1.21
2024-01-31 17:27:19 sqlite (shidel): TR package description updated
2024-01-31 17:26:41 fdnpkg (shidel): TR translation update
2024-01-31 17:22:46 clamdb (shidel): TR package description updated
2024-01-31 17:13:40 project_FD-NLS (shidel): Merge pull request #185 from 
cardpuncher/master
2024-01-31 17:11:54 project_FD-NLS (shidel): Merge pull request #183 from 
andrewbird/kittenc-fixup

Thanks to Willi for pointing out the software that needed updated.

Jerome






___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDISK does not respect DLASortByDriveNo config of the kernel

[Eric Auer via Freedos-devel]

Hi Bernd,

I would assume the kernel parameter is neither meant to be queried
at runtime nor is it used by a significant number of people at all.
There is no external API, but you may pull it from RAM, possibly.

Alternatively, you could extract settings from the kernel file of the
boot drive or (better?) try and compare your view of which drive is
which to the kernel in terms of sizes and labels for local drives.

But if you ask me, a command line option for that non-default,
but POSSIBLE sort order should be enough for FDISK. Anything
beyond that feels like unnecessary luxury and complexity to me.

I guess it could be more interesting to improve detection of whether
a disk is completely empty - no risk of damaging previous partitions
and/or boot code. Maybe improve boot code blobs offered by FDISK, too?

Also, that detection thing could provide a command line way for some
"just detect and return errorlevel" mode for use in batch processing.
Or maybe that feature even already is there? :-)

Greetings and happy new year everybody, Eric




Hi,

while hunting a FDISK  bug reported to me on Github regarding the order 
of the drive letters FDISK assigns, I noted that the FreeDOS Kernel 
actually supports different drive sorting algorithms via its 
DLASortByDriveNo config setting. While it is unrelated to the bug, this 
may impose a problem if the FreeDOS Kernel and FDISK disagree over the 
drive letters. For example, the user could be confused and delete the 
wrong drive.


Taking this under account I think it would make sense for FDISK to adapt 
to the Kernel setting, or does anything speak against it? Can I query 
the DLASortByDriveNo Kernel parameter at runtime? And if so, is there an 
intended way to do this?


Greetings, Bernd






___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] special old DOS software looking for a place online

[Eric Auer via Freedos-devel]

Hi everybody,

thanks to help from two men, NEWTRACK is on track again!

In other words:
https://auersoft.eu/uni/newtrack-eyetracker/
and
https://auersoft.eu/soft/
are working again and there even is a new mirror:

https://m.lod.bz/auersoft.eu/soft/
etc.

Thanks to Jerome and Tassilo for mirror and resurrection!

At https://fd.lod.bz/ you also find a HTML mirror of RBIL
and all that FreeDOS distro content curated by Jerome :-)

Cheers, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] initdisk question

[Eric Auer via Freedos-devel]

Hi again,


Have a look at https://gitlab.com/FreeDOS/base/kernel/-/issues/4
which wonders whether there is a bug in CHS/LBA detection/forcing,
risking to call the BIOS with invalid parameters or dividing by 0.


We found out that the problem is something else: Kernels without
FAT32 support will just say "initdisk" and not list any partitions
if you only have FAT32 ones.

Then the kernel will proceed to try to open fdconfig sys, but
because it has not found any C: drive, it will try to read the
config from A: which is extremely counterintuitive.

I suggest that kernels without FAT32 support explicitly mention
any FAT32 partitions they encounter but ignore, to give people
a clue what they are missing.

I also suggest that kernels do NOT try to read the config from
A: when you have booted from C: but there is no C: they notice.
There should be some sort of error message in that scenario.

Thanks! Regards, Eric





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] initdisk question

[Eric Auer via Freedos-devel]

Hi!

Have a look at https://gitlab.com/FreeDOS/base/kernel/-/issues/4
which wonders whether there is a bug in CHS/LBA detection/forcing,
risking to call the BIOS with invalid parameters or dividing by 0.

Regards, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] special old DOS software looking for a place online

[Eric Auer via Freedos-devel]

Hi developers!

As you may remember, I wrote a rather specialized eyetracking software
called NEWTRACK *long* ago. It is open source, written in DJGPP GNU C
and works with dual PCI VGA/VESA graphics. Given that I have no working
web domain at the moment, would anybody be interested in mirroring it?

The whole directory with docs (PDF and PS.GZ), CWSDMPI and index.html
is less than one megabyte in size. This software is for eye-tracking
with eyetrackers with analog output and two simple bit-banged LTC1286
A/D on the printer port, which also has reaction buttons wired to it.
Example adapter schematics are included as eps and fig graphics files.

You can imagine that this feels rather "retro" today. Everybody uses
cameras and image processing instead for tracking eye movements today.

Still the software is interesting, among other things, as example
for dual PCI (or PCIe) VGA access with VESA on one screen for PCX.
It has precision timestamping with RDTSC, too :-)

Thank you! Regards, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Phishing attack - warning!

[Eric Auer via Freedos-devel]

Hi everybody,

now I have also received one of those freedos phishing mails:
test at multicenter.com.bo wrote "Re: [Freedos-devel] mode.com"
from 193.201.8.100 saying: Please review and sign the enclosed
document. This is essential for our current project (etc.)

The link in the mail interestingly was a doubleclick forward
to a bitly link. Luckily, bitly offers a link preview and
virustotal helped me to find out more. The link had checked
out as harmless 13 days ago, but a "reanalyze" now tells me:

https://www.virustotal.com/gui/url/ff13f15b868cc0b4efdb580f44b621d8f435b82e4fbb6e6fe1cef9327d3fb441/detection

Malware (ESET, Lumu, SOCRadar, VIPRE)
Malicious (Seclookup)
Phishing (Fortinet)

Details about the type of malware are not provided, though.

It is interesting that the previous check was around the
beginning of this phishing or malware wave. Maybe those
sending the mails themselves had their now-infected sites
checked before infecting them, for a fake sense of security?

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] VME broken on Ryzen CPU, autodetection useful?

[Eric Auer via Freedos-devel]

Hi! I just got reminded that (2017 news)

http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/

VME is broken on AMD Ryzen of that time. That sounds like
something which would be relevant for JEMM386, because it
could automatically activate NOVME mode for affected CPU.

Does anybody remember whether it does? And whether AMD
has fixed the issue in later Ryzen or other CPU versions?

Regards, Eric

PS: For Win9x fans, there is a binary patch for VMM VXD
https://github.com/JHRobotics/patcher9x In VMWare, one
also had to manually select AMD-V virtualization? More
hints on Win9x, in German, can be read on creopard.de



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] ACPI infos with ACPItool

[Eric Auer via Freedos-devel]

Hi!

A few months ago, Laaca has released AcpiTool 1.1c and 1.2b:

http://www.laaca.borec.cz/soubory/acpitool.zip

It shows ACPI info in DOS. The BTTR thread here

https://www.bttr-software.de/forum/board_entry.php?id=20351=0=time=0

discusses the update to ACPItool 1.2b:

Now I wonder whether this is still the official tested
version or whether more testers are needed or even
newer versions have been released already? :-)

Thanks for the tool, Laaca!

Regards, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] i have a tech question about 286 and XMS

[Eric Auer via Freedos-devel]

Hi!


FDXMS286.sys is the driver i am using
it works with wolf3d code but not the dos game code. i made a work around
but there might be a bug in that xms driver's code


Please be more specific about what went wrong and which
work around in which code snippet resolved the problem.
I think a workaround in FDXMS286 could be a good idea.

Regards, Eric





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] i have a tech question about 286 and XMS

[Eric Auer via Freedos-devel]

Hi!


is there any supported XMS driver for 286 that FreeDOS provides? himemx
dose not support it and the fd286xms driver is old and not supported. maybe
i could work on it.

yes i have a 286 xD
it's just frustrating that everything requires a 386


If I were you, I would just use FDXMS286 and report any
issues you encounter. Somebody may help with a patch :-)

Eric





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Help Development with djgpp

[Eric Auer via Freedos-devel]

Hi!


I have no knowledge for protected mode. I think you need this for
OpenWatcom C compiler. This is the only reason to use DJGPP compiler. Am I
right?  Else the initializing you show on the YouTube Videos is very simple
for OpenWatcom.


I think (check the youtube videos with examples by Jim) OpenWatcom C
ships with libraries for convenient graphics access functionality.

Both OpenWatcom C compiled 32-bit apps and DJGPP compiled 32-bit apps
automatically use protected mode, for example by calling or including
a DOS extender or DPMI host, so you do not have to know how to use it
on the hardware level unless your apps have to do very special things.

However, because they (and all other 32-bit C compilers, I assume)
use protected mode, some things will work differently compared to
what you would see in, for example 16-bit Borland Turbo C apps.

For example access to raw memory locations or hooking int handlers
will be different. On the other hand, once you include the right
header files and use the right calls, 32-bit compilers let you do
MORE. A good example is being able to map a large high resolution
graphics framebuffer above the 1st MB of RAM to a simple C array.

For app-internal purposes, using 32 bits is trivial: You can malloc
larger amounts of memory and use larger variables and arrays. Your
pointers will often be 32-bit unsigned integers instead of either
16-bit (tiny and small 16-bit model) or pairs of 16-bit (large or
huge 16-bit model) values which you may know from 16-bit compilers.

Only for special cases, pointers will combine 32-bit offsets and
16-bit selectors values, but macros will help you in those cases.

Here are some examples for directly accessing individual bytes or
words (for dwords, use farpeekl and farpokel) in 16-bit DOS RAM
while the rest of your app naturally works as 32-bit application.

#include  /* things like inportb() */
#include  /* only for _dos_ds... */
#include  /* e.g. _farpeekb(_dos_ds, linear) */
#include  /* int86, union REGS */

typedef unsigned int uint32;

/* o is offset, s is segment, v is value. All of them "DOS-wise": */
#define peek(s, o)  _farpeekw( _dos_ds, ((uint32)(s)<<4)+(o) )
#define peekb(s, o) _farpeekb( _dos_ds, ((uint32)(s)<<4)+(o) )
#define poke(s, o, v)   _farpokew( _dos_ds, ((uint32)(s)<<4)+(o), (v) )
#define pokeb(s, o, v)  _farpokeb( _dos_ds, ((uint32)(s)<<4)+(o), (v) )

Because the first megabyte is special (shared with DOS, with
predictable absolute addresses of some data structures etc.)
you have to access it with macros like farpeekw or farpokew,
using the pre-defined "_dos_ds".

Similarly, to access a frame buffer, you pin the memory area and
create a selector for it, then read and write pixels with farpeek
(b, w, or l for 8, 16 or 32-bit values) and farpoke (b, w, or l).

#include/* to call the BIOS -- or use dos.h */

__dpmi_meminfo memory_mapping;

   memory_mapping.address = the physical linear address of your frame 
buffer according to what the VESA BIOS told you when you selected a 
graphics mode of your choice.
   memory_mapping.size = the size of your framebuffer in bytes. Note 
that the number of bytes per line can be larger than screen width * 
bytes per pixel. Use what the VESA BIOS tells you.


   __dpmi_physical_address_mapping(_mapping);
   __dpmi_lock_linear_region(_mapping);

   int lfbSel = __dpmi_allocate_ldt_descriptors(1);
   __dpmi_set_segment_base_address(lfbSel, memory_mapping.address);
   __dpmi_set_segment_limit(lfbSel, memory_mapping.size - 1);

Now you can access the framebuffer by defining a macro such as,
in this example for 16-bit (32k or 64k high color) and true color:

#define putpixel16(x,y,c) _farpokew(lfbSel, \
  (((x)*2) + (vesamode.bytes_line*(y))), (c))

#define putpixel32(x,y,c) _farpokel(lfbSel, \
  (((x)*4) + (vesamode.bytes_line*(y))), (c))

For NORMAL variables or arrays, where you will NOT need to
know which absolute linear memory addresses are used, you just
use NORMAL pointers as you would do in Linux apps. No macros.

You can also call the BIOS using __dpmi_int(...) to have extra
control over how mappings are treated, but DJGPP will handle
many popular cases AUTOMATICALLY if you use int86(...) with
__dpmi_regs from dos.h, for example if you want to call a
mouse driver via interrupt 0x33.

So you will often NOT need to use _dpmi_allocate_dos_memory()
or _dpmi_free_dos_memory(). Instead, you will use DJGPP library
functions for all common things. Accessing files will feel not
so different from accessing files in Linux with GCC compiled
apps, of course within the file size limits imposed by DOS.


SVGA is possible with the used board by installing a firmware.


Again, do you also have firmware for VESA VBE framebuffers?
That would make access fast and convenient. Of course, if you
use the graphics library of OpenWatcom C, or if you use the
Allegro library available for DJGPP, none of the convenience
issues will matter for you, as the libraries will do all the
work. 

Re: [Freedos-devel] dir issues

[Eric Auer via Freedos-devel]

Hi!


VCPI was a superset of EMS, right?


I don't think so, no.


VCPI can be added to EMM386 to let it coexist with DOS extenders.
VCPI itself does not provide EMS.

EMS can exist in hardware on 8086, where DOS extenders cannot exist.
EMS itself is not related to VCPI.


The other complication was the different versions (e.g. XMSv2 versus
the bigger 386 variant v3)


I don't think I remember _versions_ of XMS. EMS, yes.


XMS 2 only supports up to 64 MB, XMS 3 supports more.

Because you cannot have so much XMS on 286, the XMS 3
interface is designed specifically for 386 and newer.

EMS 3.2 only supports pages of 16 kB size in a single
64 kB page frame at a fixed location, like "d000:".

EMS 4.0 supports 4 kB pages and lets you put them at
any multiple of 4 kB place in the first megabyte. It
no longer needs a page frame. EMM386 NOEMS actually is
for "no frame, 4.0 access only", not to disable EMS.

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] ANSI for DOS

[Eric Auer via Freedos-devel]

Hi!


There are other base components in FreeDOS, such as CuteMouse that do not 
support an 8086.


That should be a almost compile time option. If neither .286 nor .386
are set early in the code, neither USE_286 nor USE_386 should trigger
and you should get an 8086 compatible variant. However, I do not
remember which variants support that. 2.1beta4 for JWASM maybe?
The 8086 variant will use slightly more RAM when resident etc.

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] dosshell and task swapping, was: dir issues

[Eric Auer via Freedos-devel]

Hi Rugxulo,


[3] Windows 3.0 started to catch on. That meant HIMEM.SYS and XMS as
standard; LIM-spec EMS started to fade. Apps like 1-2-3 r3 used DOS
extenders routinely. Memory management really got important but
everyone was buying 386SXs so you could sell them QEMM even if they
didn't want Windows.


VCPI was a superset of EMS, right? That was co-designed by QuarterDeck
(DesqView company), right? It was meant to make multitasking more
stable, but DPMI (later invented for Windows 3.0 but also implemented
elsewhere) was much better designed and more popular.


VCPI was a small interface added to things like EMM386 which gave other
apps access to things they would normally no longer reach after DOS gets
locked up in a VM86 task by EMM386. While it is nice that it is small,
it is not so nice that it basically lets you kick out other protected
mode things to use them yourself. DPMI is significantly larger, but it
lets you use protected mode in s far more cooperative way. Which is why
protected mode hosts like DOSEMU and Windows would typically only offer
DPMI, not VCPI, because VCPI is too raw metal, too little cooperative.

Note that DOSEMU2 has moved on to simulate the whole CPU anyway, which
lets DOS apps use all protected mode stuff they want, and which lets
DOSEMU2 run on CPU architectures which would not run DOS in hardware.


Since the XMS standard and support was so "late", several compilers
(e.g. Turbo C) only enabled "use EMS" by default.


I doubt that. With EMS, you could virtually swap 16 kB pieces of RAM
from above 1 MB into the low 1 MB, later also more fine-grained 4 kB
pages. With XMS, you can only copy around memory. So if your compiler
only knows how to generate code which runs in the first 1 MB, only
EMS can help you to run large code. If your compiler uses protected
mode, then it only needs some way to gain access. It could use raw
real mode as starting point and allocate RAM listed by the BIOS. It
could allocate XMS and make sure the XMS memory copy routing and your
code would not get a conflict about protected mode. Or it could use
VCPI to take over from EMM386 or similar. As this is sort of messy,
there are also compilers which use DPMI based DOS extenders, such
as DJGPP with CWSDPMI: The latter can either work with DPMI offered
by some other software, such as Windows, or bootstrap from one of
the listed other starting points into providing DPMI for your app
itself, so your app only has to deal with ONE interface: DPMI :-)

Note that you can also have EMS with mainboard hardware assistance
on pre-386 CPU and even on some early 386 mainboards. If you use
that, it will have nothing to do with protected mode, though.


In fact, quite a few
apps and games were "EMS only", even 386+ programs. (It was only DJGPP
v2 in 1996 where they went "DPMI only".)


Are you sure you mean apps? Maybe specific DOS extenders? Which?

Regards, Eric

PS: I do think DOSSHELL with task swapping was nice. We had threads
on FreeDOS lists wondering whether TriDOS would be okay for that, but
that "Tripple DOS" is a pure swapper. No file manager included and
it wants to be loaded instead of HIMEM. It is not EMM386-compatible
and there were plans to make it DPMI-compatible or let it offer DPMI
itself, but for now, it only offers XMS. It can do swapping even of
graphical apps, but only for classic VGA modes. By Vadim Drubetsky.




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS code page Unicode compatibility

[Eric Auer via Freedos-devel]

Hi!


If you’re interested about the whole forint sign issue, read my Unicode
proposal and its follow-up:

https://www.unicode.org/L2/L2023/23060r-forint-sign.pdf
https://www.unicode.org/L2/L2023/ ... -forint-sign-follow-up.pdf


The way in which the follow-up quotes me misses out on quite a few
relevant details for this issue. However, those who wonder about the
follow-up may just as well be interested in what we have discussed
off-list, so I quote myself below :-p I think we should investigate
which of those 30+ apps contain which amount of support for mappings
of Unicode and codepages. I was surprised that there are that many
CANDIDATES in our distro, but a candidate is not the same as an app
for which we KNOW that they contain sufficiently comprehensive support
to make them relevant for the Unicode Forint sign topic.

Because of this, please support my OTHER thread on the question:

2023-06-23 on Freedos-user:

"Unicode and codepages in apps already bundled with FreeDOS?"

My first attempt on the list of apps, off-list to Vacek, 2023-06-17:


Hi Vacek,

thanks for the CP3845 details!


Wilhelm Spiegl has replied to me since, indicating that HTMLHELP does not
use mapping tables to convert *to*, only *from* Unicode and a forint sign
is also unlikely to occur in help text.


Depends. You can use HTMLHELP as generic minimal HTML viewer.

But as it only converts FROM Unicode, one would have to agree
on a Unicode value for Forint to let it display "Unicode Forint"
in codepages which include the Forint sign. I guess you can
also use HTMLHELP for non-Unicode HTML. In that case, it will
simply have no opinion about characters, so you could use it
to view CP3845 HTML simply by letting DOS use the CP3845 font.


Other projects may have stronger cases to include the mapping, so thank you
for the list, I’ll check whether any of these projects fit the scope of my
project and contact the maintainers.


I think it would be good in general to have a list of apps for
which Unicode and/or codepage conversions are  supported, not
supported or status is unknown. That list could start with the
30+ apps mentioned in my mail. Then you could check the docs,
and sources to reduce the number of unknowns. Next step could
be to ask about the rest on the FreeDOS mailing list and only
for those where no other mailing list readers know the answers,
you would have to ask the maintainers 

Of course I do not know whether you plan to spend much time for
this. But as said, it would be good to know how far our distro
is when it comes to Unicode support and related codepage tricks.


Do you allow me to cite relevant parts of your letter in a document relayed
to the people in charge for my Unicode proposal? It definitely suggests
there are numerous applications ‘bridging’ FreeDOS and Unicode, which
support my stance that 1:1 mapping of this DOS-derived character ligature
is needed and substitution with a regular letter sequence “Ft” as suggested
by the Unicode Consortium is not an option for these purposes.

I think the existence of projects like those listed would be already enough
impetus for the Unicode Consortium to move forward, then if and when a
stable code point assignment is made (the next UTC meeting is in July) I’ll
notify any maintainers interested.

Thanks for your help,
Vacek


I do not think that my mail will help you in any way with the
Unicode people at this moment: I simply went through the list
of the apps in our distro and, to my own surprise, found more
than 30 for which I BELIEVE that there is a CHANCE that they
include Unicode support or at least some type of translation
between codepages.

You will first have to find out how many of those REALLY have
the features for which we hope that they may have them.

In the end, you could argue along the lines of this thought:

With DOS, including the actively supported free open source
distro FreeDOS, people have been using fonts with Forint sign
for decades. In DOS, this required selecting an 8-bit mapping
(code page) which includes the sign, so people had to decide
whether they wanted to work with a font with Hungarian Forint
and other Hungarian characters or with a font which includes
other accented characters common in other languages. Unicode
aims to solve the problem of having to switch fonts for text
in different languages. It makes it possible to use one font
which supports many languages at the same time. However, this
also means that all different characters have to be assigned
to globally unique Unicode code points. At the moment, there
is the unusual situation that a widespread and very old font
mapping supports a currency symbol which is yet unknown to
the very newest version of Unicode: The Forint sign. So it
is not possible to exchange text including that sign in new,
Unicode based file formats. Only old 8-bit formats which are
in use already since DOS became popular are supported, which
is good for modern-day DOS users but bad for Unicode users.

FreeDOS