Re: [Freedos-user] cannot boot installation media

[tom ehlert via Freedos-user]

Hallo Herr Davi Ramos via Freedos-user,

am Sonntag, 28. April 2024 um 05:28 schrieben Sie:

> So, as I said in another message, I have a computer where I wish to install
> FreeDOS. It is a *Compaq Presario 427, Intel Pentium N3700, 4GB RAM, SSD
> 240GB, and a 14" screen.*

> Unfortunately, I cannot get it to boot the installation media
> .
> I have tried numerous USB flash drives as well as an SD card.

100 messages later we still don't know what "I cannot get it to boot" exactly 
means, as in

a) the stick is not detected
b) the stick is detected but ignored
c) refuses to boot the freedos strtup files
d) what does the screen look like in your failed boot attempts,
or does it continue to boot from hard disk?

if the stick isn't detected at all it doesn't matter if you put windows, linux 
or freedos 
on the stick or if your BIOS is running in UEFY or LEGACY mode


Tom





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

Re: [Freedos-user] cannot boot installation media

[tom ehlert via Freedos-user]

> Eh... I tried every single BIOS setting 

at least on my Dell notebook there is no such *setting*.

instead I have to hit F12 while booting, this then sends me to a "select boot 
device",
where I can tell it to boot from USB

Tom



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

Re: [Freedos-user] Dial-up emulation?

[tom ehlert via Freedos-user]

> Indeed, I'm using an old-school program called Qmodem.

>  My question now is – would I be able to use the Internet using the emulated 
> modem?
yes (if you had any idea what you are doing). But definitively not with QMODEM.

Tom


> Brandon Taylor
> 
> From: Jim Hall via Freedos-user 
> Sent: Tuesday, April 23, 2024 10:12 PM
> To: Discussion and general questions about FreeDOS. 
> 
> Cc: Jim Hall 
> Subject: Re: [Freedos-user] Dial-up emulation?



> On Tue, Apr 23, 2024, 9:38 PM Brandon Taylor via Freedos-user 
> mailto:freedos-user@lists.sourceforge.net>>
>  wrote:
> Since FreeDOS doesn't support physical network hardware (even if it's 
> emulated in a program like PCem or 86Box), I figure there's no way FreeDOS is 
> gonna be able to connect to the Internet, right? Well...

> The developers of the 86Box project have recently implemented emulation of a 
> Hayes-compatible dial-up modem. So my question is... will FreeDOS support the 
> emulated modem?


> Well, it's not that "FreeDOS" would support the Hayes modern, but that 
> terminal/dialer software would then be able to. FreeDOS is not like Linux, 
> which uses a Hardware Abstraction Layer (HAL) to support the hardware 
> directly. FreeDOS, like any DOS, does normal DOS things and leaves certain 
> hardware access (like playing sounds through a sound card, or accessing a 
> network to browse the web or check email, or dialing out through a modem) to 
> other software.

> So if you had a terminal/dialer program like Procomm or Telix, then yes, I 
> expect you'd be able to dial out through this emulated Hayes modem from 
> FreeDOS.





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

Re: [Freedos-user] Portuguese keyboard layout

[tom ehlert via Freedos-user]

Manuel,

> Tom, thank you for the update, however the problem persists with version
> 0.52.

iT looks like Daide forgot To update this mkeyb.exe.

howeer from The source directory or 
https://github.com/davidebreso/mkeyb/blob/main/mkeyb.exe
 
does produce '*' and '+'.

Tom 



> Regards,
> Manuel

> On Tue, Mar 19, 2024 at 5:12 PM tom ehlert via Freedos-user <
> freedos-user@lists.sourceforge.net> wrote:

>>
>> > Same problem, don't think that there is a solution.
>>
>>
>> The current MKEYB should have this problem resolved.
>>
>> https://github.com/davidebreso/mkeyb/releases/tag/v0.52
>>
>> Tom
>>
>>
>>
>> ___
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>





Mit freundlichen Grüßen / with kind regards
Tom Ehlert
+49-15151898538



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

Re: [Freedos-user] Portuguese keyboard layout

[tom ehlert via Freedos-user]

> Same problem, don't think that there is a solution.


The current MKEYB should have this problem resolved.

https://github.com/davidebreso/mkeyb/releases/tag/v0.52

Tom



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

Re: [Freedos-user] Coding in BASIC for Freedos?

[tom ehlert via Freedos-user]

Hi Jim,

> On Sun, Mar 17, 2024 at 6:26 AM Liam Proven via Freedos-user
>  wrote:
> [..]
>> There are good reasons that DOS went away some 35 years ago. It has
>> its uses but not being able to flip to another window or another
>> screen to consult documentation, or try something out, or look it up
>> online, is a *massive* handicap.

+1

> That's a very interesting way of "advocating" FreeDOS, and "helping"
> folks who are new to FreeDOS.
I think Liam's post was not about "advocating" FreeDOS, but about "helping"
a nooby user.



> Here we have a person who discovered FreeDOS, who wants to experiment
> with FreeDOS by writing programs with it, and was looking for pointers
> to get started. 
Nope. AFAICT it's a person wanting to learn programming; no mentioning of 
FreeDOS.

And learning FreeDOS and learning programming at the same time is taking Two 
steps at once.
Usually not a smart idea.


> It's a very odd reaction to immediately tell that
> person to go find another operating system. That's not very welcoming.

> If someone discovers FreeDOS and wants to explore FreeDOS, we should
> help them find a way to "Yes" and not to "No."
it should be a serious reply.
in this case I'd vote "probaly not unless the original BASIC is a DOS based 
BASIC".
even then use a 32 Bit version of Windows(if the intended use case is learning 
to program). 


> And if something goes really wrong (like you did
> something weird in a new program you wrote, and it crashes and locks
> up the system) you just reboot.

I simply guarantee that you won't be able to write a program that crashes any 
version of modern Windows Dosbox.
I fail to see the advantage.

Tom  



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

Re: [Freedos-user] AUTO SHIFT keyboard on DOS??

[tom ehlert via Freedos-user]

Hallo Herr tsiegel--- via Freedos-user,

am Donnerstag, 8. Februar 2024 um 23:41 schrieben Sie:


> On 2/8/2024 3:34 PM, tom ehlert via Freedos-user wrote:

>> only problem would be that your typin speed is now limited to 1 haracter per 
>> e.g. 500 milliseconds.
>> not very practical.

> Not at all.  A keyboard driver is going to know when a key is released, as 
> well as when it's pressed.  Nothing preventing it from operating normally 
> when it's released fast enough, and only shifting the character if it isn't 
> released in the alotted time. It doesn't restrict typing speed in the least 
> (with the exception of course of making the capital letters.).

rethinking this, you are right.

if the scancode is interpreted/send to the BIOS as soon as some other scancode 
is detected
(either other key depressed or key-released) typing speed would not be limited.

only "do you agree Y/N" would be limited if you HOLD the Y key. probably not a 
problem.

> I've never tested it, but if you have key repeat turned off, then it's likely 
> the character doesn't appear until you release the key anyhow, so ... 

yes, this feature would require BIOS key repeat and replace it with "automatic 
shift".
I don't see a big problem here as long as this is choosable. 

big problem here is that noone will implement it. 

even bigger one that DOS/WINDOWS/Linux/MacOS would be different. I SHOULD HAVE 
WRITTEN THIS IN ALL CAPS.

Tom
   



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

Re: [Freedos-user] AUTO SHIFT keyboard on DOS??

[tom ehlert via Freedos-user]

Hallo Herr Thomas Cornelius Desi via Freedos-user,

am Donnerstag, 8. Februar 2024 um 13:18 schrieben Sie:

> Hi,

> is it possible in DOS (using BIOS?) to implement a tsr or so which allows the 
> following:

> holding a key longer to return a SHIFT-key on screen?

> Example: 

> press key »a«  and HOLD the key for e.g. 500 milliseconds,  
=>> print shift-a = »A« on screen.

> Anyone around who has an idea or knowledge if this is possible or has been 
> done or any hints where to look?

this would go to the keyboard driver as only it knows to differentiate between


A-pressed A-pressed --> A

A-pressed A-released A-pressed --> a

only problem would be that your typin speed is now limited to 1 haracter per 
e.g. 500 milliseconds.
not very practical.

Tom



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

Re: [Freedos-user] MSdos 7.1 question

[tom ehlert via Freedos-user]

> On Fri, Nov 3, 2023 at 12:31 PM Ralf Quint via Freedos-user
>  wrote:
>>
>> In which way is "FreeDOS" limited to 2GB sized files? (Sorry, never
>> bothered wit such large files on DOS (any DOS)? The file size entry in
>> the FAT32 directory entry is a 4 byte integer. As a filesize can't be
>> negative, this should be a UINT_32/unsigned long and thus allow for
>> files up to 4GB.
FAT files definitively can't be bigger then 4GB (ignoring FAT+) because the 
'file size field' has only 32 bits.


I am *mostly* sure that 
file size was limited to 2GB in MSDOS < 6.2
file could grow to 4GB if you indicated 'I am aware of signed/unsigned 
problems'
  at file creation/opening time

I am *mostly* sure that 
   FreeDOS just has a 4GB limit.

it's not that complicate to test this - and ascertain or deny this.

as a side note: disks bigger then 1GB just weren't available at MSDOS times.
so this was never a theme.



Tom
 



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

Re: [Freedos-user] languages

[tom ehlert via Freedos-user]

Hi,

> i' m from Portugal and i'm aware of the portuguese layout for 43 years.
> When i press that key produces a A with a ring on top.

it helps if you say "the key right of 'P' should produce '+' and '*' in shifted 
state.

and indeed mkEYB has this wrong (for whatever reason).

i just filed this as an issue on the GITHUB project page.
Tom



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

Re: [Freedos-user] languages

[tom ehlert via Freedos-user]

Hi,

> It's been a while since i use freedos on asus eeepc with portuguese from
> portugal and if i recall i can't write the * with shift and *+" key and
> since there is no numeric keypad.

a) what keyboard driver are you using?
b) IIRC (20 years later) there was 'portuguese' and 'portuguse brazil'.
   which one?

>  "i can't write the * with shift and *+" key"
c) about the worst bug complaint ever. you don't deserve a better keyboard 
driver ;(

Tom






> I haven't tested on a vm...

> On Fri, Sep 29, 2023 at 9:03 AM Eric Auer via Freedos-user <
> freedos-user@lists.sourceforge.net> wrote:

>>
>> Hi!
>>
>> > FreeDos need's update in the keyboard and languages, there is support for
>> > that in open-source environments, but I don't know how to implement them.
>> > For example I'm using a portuguese keyboard and it doesn't support it, so
>> > Iam in trouble's
>>
>> Actually FreeDOS has no problems with Portuguese keyboards. Even
>> the tiny MKEYB driver supports them. If you run MKEYB /? you will
>> see that MKEYB /L shows a list of supported keyboards, which does
>> include Portuguese. So you could run MKEYB PO to activate keyboard
>> support in Portuguese style, or you could add a line saying MKEYB
>> PO to your autoexec.bat or fdauto.bat, depending on which of the
>> two you are using. Our other keyboard drivers also support your
>> layout, you just have to read the documentation to find out how
>> to activate it, as they are a bit more complicated to set up :-)
>>
>> Best regards, Eric
>>
>>
>>
>>
>> _______
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>





Mit freundlichen Grüßen / with kind regards
Tom Ehlert
+49-15151898538



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

Re: [Freedos-user] picoTCP: a modern, open-source TCP/IP stack for DOS

[tom ehlert via Freedos-user]

Hallo Herr Aitor Santamaría via Freedos-user,


> What is LIDOS?
> (Couldn't find any reference on the Internet)

it might help to use the intended spelling "Lidux"

Tom


> Aitor


> On Fri, 20 Nov 2015 at 17:08, Alain Mouette  wrote:

>> Due to zero interest in the VM with Linux+FreeDOS that I uploaded, it is
>> unprobable that LIDOS will get much work done...
>>
>> Remember that for FreeDOS, picoTCP is all about applications, so nothing
>> needs to be done and should work out of the box in that VM
>>
>> And anyway, I don't know how to run a DOS graphic program using Lidux
>> hardware drivers. This is a real show stopper :(
>> If anyone knows how to do that, things may get interesting...
>>
>> Alain
>>
>>
>>
>> On 20-11-2015 11:34, Geraldo Netto wrote:
>> > Once again my overflow of gratitude:
>> >
>> > while (1) {
>> >   Mateusz++;
>> > }
>> >
>> > Alain, maybe we could update LIDOS with Mateusz picoTCP
>> >
>> >
>> > Kind Regards,
>> >
>> > Geraldo Netto
>> > Sapere Aude => Non dvcor, dvco
>> > http://exdev.sf.net/
>> >
>> >
>> > On 19 November 2015 at 17:00, Mateusz Viste  wrote:
>> >> Hello group,
>> >>
>> >> I write this message to share a little news about what I was doing in my
>> >> spare time these last two months: porting picoTCP to DOS.
>> >>
>> >> picoTCP is a modern, dual-stack, open-source TCP/IP stack. It has been
>> >> created by the good people at Intelligent Systems (Altran), primarily as
>> >> a stack designed for embedded computing (hence hardware with very
>> >> limited horse power). It is backed by a well established corporation and
>> >> it's actively maintained.
>> >>
>> >> I played with the stack for some times now, and ended up building an
>> >> entire DOS compatibility layer around it. A few patches were required to
>> >> the stack, a few days of development, many hours of debugging - but here
>> >> it is - the first public release of picoTCP for DOS!
>> >>
>> >> http://picotcp4dos.sourceforge.net
>> >>
>> >> The project contains three major parts:
>> >>
>> >> - ipcfg: a little tool that allows to configure networking on your DOS
>> >> machine (IP, DNS, etc). No, it's not a text file - I wanted to avoid the
>> >> complexity of parsing a text file, and opted for a binary configuration
>> >> file that is manipulated via ipcfg. It's much more flexible that a text
>> >> config file, while being much easier/faster to load at runtime.
>> >>
>> >> - ping: no need to explain, I guess... my ping tool for DOS, based on
>> >> picoTCP - crucial when it comes to testing your networking
>> >>
>> >> - an OpenWatcom library package (openwatcom, large memory model) - this
>> >> is for the fellow developers that would like to use the DOS version of
>> >> picoTCP inside their network-enabled, 16-bit DOS programs. I integrated
>> >> a packet driver schim, a DOS-compatible timer, as well as the whole IP
>> >> configuration logic, so it is now a simple (2 functions!) public API
>> >> that allows to load picoTCP, use it, and unload it.
>> >>
>> >>
>> >> *** Short how-to ***
>> >>
>> >> 1. Download picotcp4dos and unzip it on your drive
>> >> 2. Set the location where the config file will be stored, for example:
>> >> SET PICOTCP=C:\PICOTCP.DAT
>> >> 3. Bind picoTCP to the interrupt vector of your packet driver, example:
>> >> ipcfg int 60
>> >> 4. Configure your IP settings using ipcfg, or use DHCP (ipcfg dhcp)
>> >>
>> >> enjoy!
>> >>
>> >> Mateusz
>> >>
>> >>
>> >>



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

Re: [Freedos-user] Accessing usb stick from freedos.

[tom ehlert via Freedos-user]

>> The alleged 4 GB file size doesn't work on some OSes (FreeDOS, Windows
>> NT?), only on old Win9x. So you're only guaranteed 2 GB individual
>> file sizes, universally.
> Wrong. You can use files of up to 4GB size on any Windows version that 
> supports FAT32. So does any reasonable version of Linux. Yes, some OS might 
> limit you to 2GB, as they are using a signed 32bit integer, but that is far 
> from being "universally".

the problem here is probably that early OS versions had checks that the file 
pointer was never moved below zero.

i.e. 
  move to 1.5 GB
  read stuff.
  move to 3.7  GB (which is 2.2 GB which is negative 1.8 GB)
  // what is the OS supposed to do?


the 'solution' was (IIRC) to require applications in the OPEN call to 
indicate "yes, I understand 32 bits"

FreeDOS does this by default.



Tom




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

Re: [Freedos-user] Accessing usb stick from freedos.

[tom ehlert via Freedos-user]

> Newer version of Windows seem to have problems with accessing 
> drives/partitions over 32GB as well. 

I would be seriously surprised. Windows refuses to *format* drives above 32GB 
as FAT32, but simply
works with it up to maximum capacity of (2^32 * sectorsize) which is usually 
2TB.

FreeDOS doesn't support sectorsizes other then 512, so anything up to 2TB 
should be supported. 


Tom



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

Re: [Freedos-user] Basic freedos question before I try this?

[tom ehlert via Freedos-user]

> I have it myself already, unless there has been a update, but wanted to ask.

please explain this. 

Tom



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

Re: [Freedos-user] Dosemu on its own - does it exist?

[tom ehlert]

> Hi,


> I am a bit late but...
+1

> On Wed, 2 Sept 2020 at 15:50, ZB  wrote:

> If I'm correct, Dosemu uses "virtual x86 mode" of 386 and later processors.
>  But Dosemu of course needs "host OS".

>  I wonder does there exist any utility that offers "virtual x86 mode" and
>  acts as "host" by itself? Suppose we have (quite modest for today) computer
>  with 386/486 and 4 MB RAM. Theoretically it should be possible to run quite
>  comfortably four DOS "instances" each one having 1 MB just for itself - and,
>  say, switching among them with - like among consoles in Linux.

>  So concentrating on using DOS - because 486 is much too "weak" for Linux of
>  today - I mean utility whose duty is just to switch CPU into "virtual x86
>  mode", split RAM among established "instances" and then just share hardware
>  resources (keyboard, CD-ROM, video, sound... everything) among them.

we have DeskView386 which does exactly what you describe.

Tom



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

Re: [Freedos-user] CD-ROM Initialization

[tom ehlert]

Hallo Herr Adilson Enio Pierog,

am Mittwoch, 15. März 2023 um 19:19 schrieben Sie:

> Hi.
> I installed FreeDOS normally but the CD/DVD-ROM drive is not working.
> During initialization the following message appears:

> "Attempting to use the UDVD2 CD driver, error #255 - failed.
> Unable to load an appropriate CD/DVD driver".


> My machine is a Dell Optiplex 790. The CD/DVD drive is working fine under 
> Windows.
> What can I do?

your BIOS uses AHCI to access the disk and CD-ROM, but UDVD2 supports
only SATA mode.

use AHCICD https://rloewelectronics.com/distribute/AHCICD/1.1/


or you have to set this to SATA, 'LEGACY' or similar.

unfortunately your windows will only boot with AHCI if so installed.

Tom



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

Re: [Freedos-user] Can you recommend a good single-board-computer for legacy OSs?

[tom ehlert]

> I'm looking for one that's mass produced, just like Arduinos and
> Raspberry Pis are mass produced hobbyist computer boards.  The only
> problem with those is they don't support intel CPU instructions.

ROFL

Tom



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

Re: [Freedos-user] [ANNOUNCE] E100PKT 0.3

[tom ehlert]

Hallo Herr Seth Simon,

am Sonntag, 19. Februar 2023 um 08:42 schrieben Sie:

> Hi,

> I've fixed a bug in E100PKT (not to be confused with E1000PKT), my 
> Ethernet driver. The bug was an oversight of mine. As a sanity check, my
> code aborted if the CSR IO BAR's size wasn't 0x40, because that's how big
> it is based on the diagram on pages 39-40 of 8255xeth.pdf. However, I 
> failed to notice the accompanying text where it said that older devices
> have fewer registers. I've modified the sanity check to accept any size
> from 16-512 (I don't use anything past 16 anyway).

> It's available at gopher://sdf.org/1/users/sethsimon/e100pkt

luckily also on

https://gopherproxy.meulie.net/sdf.org/9/users/sethsimon/e100pkt/0.3/e100pkt.zip

Tom



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

Re: [Freedos-user] Anyone want to write an article about FreeDOS?

[tom ehlert]

>> programming *on* DOS in the year 2023 is like self flagellation. you
>> are absolutely allowed to do it; it's just not recommended.
> Why not? It worked just fine for all intends and purposes for two 
> decades, so why would that not be "recommended" to do so in 2023?

because programming can be MUCH more productive when you have multiple
windows open, each much better then 25*80, can google stuff while editing,
look at your source while debugging and much more.

it worked - yes. like a hand drill, and hand saw, or other late 1800 stuff.
whatever you do - you are probably using electric stuff these days.
unless you are an archeologist, trying to rebuild a medivial castel
with medivial tools only.


> That is the part that I think is the true fallacy that too many people
> perpetrate these days, when claiming to be interested in (Free)DOS.

when 'interested' in DOS, you should use edlin and a XT machine with a
big 20 MB disk for the real experience.

Tom



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

Re: [Freedos-user] Anyone want to write an article about FreeDOS?

[tom ehlert]

> The use of (n)curses for example is a typical Unix thing, that has 
> nothing to do with DOS and should not be shoehorned into a DOS 
> application...

add DEVICE=ANSI.SYS to your config.sys and you can easily 'port'
(=compile and fix C compiler discrepacies) your curses  programs to
DOS.


>>
>>> Some *ix utilities MIGHT be useful for the use on DOS,
>> MKS Toolkit? GNUish? EMX? DJGPP? Heck, even Simtel and Garbo had a few.
> I said "some" utilities. Not everything plus the kitchen sink.
>>
>>
>> "The Lessons of Unix Can Be Applied Elsewhere"
>>
> Nice statement, but I think that this is wrong. And just for the record,
> I used my first Unix system before I used my first DOS system...
> Unix was from the start to be an abstraction of the hardware underneath,
> running on different hardware, usable with minimal knowledge of the 
> hardware (specially, CPU wise).
> DOS (as in MS-DOS/PC-DOS) is directly tied to the Intel 8086 CPU, it's
> segmented memory models, it's access to an underlying BIOS (and various
> extensions) on the hardware level and out of necessity, much more 
> reliant on direct access to the hardware underneath.
>>
>>> And yes, an article, possibly a series of articles, about programming on
>>> DOS, for DOS, will be forthcoming...

programming *on* DOS in the year 2023 is like self flagellation. you
are absolutely allowed to do it; it's just not recommended.

>> I built and tested P5 Pascal (ISO 7185) with GPC (and GNU Make) for
>> DOS, Windows, and Linux.

> ISO 7185 is the worst thing that could happen to Pascal. Utterly useless
> and outdated by the time it was released.
> Same as the standards for "minimal" and "extended" BASIC. There is not
> one mainstream BASIC implementation that is really sticking to either one..
+1

Tom




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

Re: [Freedos-user] FreeDOS in proxmox

[tom ehlert]

> Right.  I thought about it later and wondered what the other DOS
> stacks did.  What does MS-NET

MS-NET is resident software, and AFAIR ping-able.

> or Trumpet do?
I have no idea.

> Probably the same thing
> as mTCP and WATTCP.

nope.

Tom



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

Re: [Freedos-user] memory issue, or something

[tom ehlert]

Hallo Herr Tomas By,

am Montag, 28. November 2022 um 16:41 schrieben Sie:

> Hi all,

> I am trying to run an old DOS game and get the following:

> |Mel Fatal Error #: 25 Trap #: 15
> |Mel Real Mode Version 2.2.5, 4/2/94

> Am using HIMEMX.EXE and JEMM386.EXE.

> Does anybody recognise this? Anything else I can try?

run without JEMM386

Tom



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

Re: [Freedos-user] VIA C7-M processor

[tom ehlert]

> Hello, I'm new to freedos, I have installed this on a nice small
> laptop, a HP 2133 with  VIA C7-M processor. It works nice, but the 386 memory 
> manager crashes.
> I do not know how to solve this.

"it works nice, but the 386 memory manager crashes."


doesn't make much sense.

as a 20+ year DOS user you should know that

a) CONFIG.SYS
b) AUTOEXEC.BAT
C) a more detailed error report of what you are doing and what the
error looks like are necessary to even start advising.


either a+b+c or simply go away.

Tom



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

Re: [Freedos-user] keyboard spacecharacter automatically repeated

[tom ehlert]

Hi,

> browsing through the email archive of the list I could not find a 
> related topic. So I try to ask here.

> My problem:

> I use a Hasu  USB converter 
> https://1upkeyboards.com/shop/controllers/usb-to-usb-converter/

> to have a "Dual function": When holding the Space-Key + an alpha-numeric
> key, tghe space bar should work as a SHIFT modifier.

> This works fine on Mac, Windows, but not with  FREE-Dos on my "HP 
> Netbook" small computers. It DOES work on a Lenovo desktop computer, 
> where I also boot FREE DOS from an USB Stick like on the HP.

> The malfunction is, that from "time to time" (actually quite "often") 
> the cursor starts to move from "alone" and wandering off creating just
> empty space, like when you would hold the spacebar down. When I hit the
> Spacebar again, the cursor stops.

> The same problem occurs when using an Ergodox keyboard where there is an
> "AUTOSHIFT" function, where you HOLD a key slightly longer then normal
> to get a "SHIFT"+character.

> Might be the BIOS differences,

this is most likely a bug in the "keyboard over USB" BIOS emulation;
there is little what you can do other then search for  a BIOS update.



> or is the keyboard controller
> automatically sending a "space" character somehow

the keyboard controller is not involved at all; the scancodes are
produced over USB


> or the FreeDos
> interprets some signal from the keyboard controller as a Key-Press

FreeDOS interprets nothing; it simply asks the BIOS if there are
characters available. If the BIOS answeres "yes, blank pressed" it
will output a blank to the screen.

of course it could be a misbehaving keyb driver  (NOT mkeyb!) but as
you don't mention a keyboard driver I assume you don't use one.

Tom



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

Re: [Freedos-user] Can't see USB stick

[tom ehlert]

Hallo Herr Travis Siegel,

am Donnerstag, 3. November 2022 um 10:46 schrieben Sie:

> Dos doesn't handle fat32 devices by default.  You'll need to load the 
> proper drivers and configure things properly for it to recognize fat32
> partitions.

in times when you are completely clueless it's always a good idea to
stay away from your keyboard.

Thank you
Tom




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

Re: [Freedos-user] can't see DVD reader

[tom ehlert]

Hallo Herr Glenn Holmer via Freedos-user,

am Sonntag, 18. September 2022 um 19:30 schrieben Sie:

> I installed FreeDOS 1.3 on a machine about ten years old. It
> successfully read the DVD during installation, but doesn't recognize it
> afterward when booted.

> How can I diagnose this?

you have a machine with AHCI, are running it in AHCI mode, and FreeDOS
has no driver automatically installed for AHCI DVD.
this is no problem when booting from DVD as the BIOS provides the
driver, but is a problem when booting from disk.

you can change this in the BIOS setup to 'legacy mode', 'SATA', ..., but then 
linux *might* have
trouble accesing both disks and DVD, depending on your setup. at least
you would loose some performance on linux.

Tom



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

Re: [Freedos-user] Ré : Networking FreeDOS 1.3 on QEMU

[tom ehlert]

> It seems I have broken packages - got networking now but having a lot
> of problems otherwise. Any easy way to square it all up again?


42

Tom



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

Re: [Freedos-user] Announce: VMSMOUNT 0.6 preview release

[tom ehlert]

Hi,



> You can get the sources, binaries and a FreeDOS package from the new site at 
> GitHub:


> https://github.com/eduardocasino/vmsmount



many thanks for this. However I can't find binaries.

Tom



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

Re: [Freedos-user] dosbox-x update available

[tom ehlert]

>> The apparent problems are the compatibility and quality. There are huge 
>> differences between Windows 9x's MS-DOS prompt and (32-bit) Windows XP's 
>> NTVDM.

> Well, yes. The Win9x DOS prompt is real DOS running on a real DOS
> kernel which can access hardware.

Well, no. The Win9x DOS prompt is protected mode DOS running on a
protected mode DOS kernel that allows your program to access hardware
as if it were in real mode.

thats no the same.

Tom



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

Re: [Freedos-user] CD drive always gets the letter H: - can't change

[tom ehlert]

Hallo Herr tauro via Freedos-user,

am Mittwoch, 3. August 2022 um 00:18 schrieben Sie:


>> Apparently on your system the letters D:-G: are already assigned to 
>> something (like maybe some USB drives or some extra partitions on the hard 
>> drive(s)?).
>>
>> You can try seeing if anything exists on the D:-G: drives (e.g., by doing a 
>> "DIR D:") and see if you can figure out what's going on.

> Thank you for your answer Bret, it came in just as I figured out by what
> was the
> problem.

> I installed FreeDOS using the LiveCD, which also partitioned my disk and
> formatted the C drive.

> Disabling the fdauto.bat and fdconfig.sys files I saw this message:

> - InitDiskWARNING: using suspect partition Pri:1 FS 0b: with calculated
> values
>  �261-254-63 instead of� 262-254-63
> C: HD1, Pri[ 1], CHS=��� 0-1-1, start=���� 0 MB, size =� 2055 
> MB
> WARNING: using suspect partition Pri:1 FS 0b: with calculated values�
> 523-254-63
>  �instead of� 524-254-63
> D: HD1, Ext[ 1], CHS=� 262-1-1, start=� 2055 MB, size =� 2055 MB
> WARNING: using suspect partition Ext:2 FS 0b: with calculated values�
> 785-254-63
>  �instead of� 786-254-63
> E: HD1, Ext[ 2], CHS=� 524-1-1, start=� 4110 MB, size =� 2055 MB
> WARNING: using suspect partition Ext:3 FS 0c: with calculated values 
> 1024-254-63
>  �instead of�� 24-254-63
> F: HD1, Ext[ 3], CHS=� 786-1-1, start=� 6165 MB, size =� 2055 MB
> WARNING: using suspect partition Ext:4 FS 0c: with calculated values 
> 1304-254-63
>  �instead of� 281-254-63
> G: HD1, Ext[ 4], CHS= 1048-1-1, start=� 8220 MB, size =� 2015 MB

> I don't know if the warning is normal, but from what I could check, the
> FreeDOS LiveCD installer by default doesn't create a single FAT32 
> partition (10
> GB HDD), but instead it creates a single 2048 MB primary partition, 
> formatted
> FAT32, and four 2 GB logical partitions, and it doesn't format them.

> Since the partitions aren't formatted, FreeDOS doesn't mount them, but
> it still
> assigns them a letter, and that explains why I had this problem. I didn't
> expect this to be the default behavior, that's why I didn't check the HDD
> partition table to see what was going on.

> To solve this, after deleting the partition table, I booted the LiveCD and
> repartitioned the disk using fdisk. It created a single 10 GB partition
> which I
> later formatted to FAT32 with the included format.exe.

> After that, the installation went flawlessly and the problem was solved.

> It would make more sense if the installer made a single FAT16 2 GB 
> partition, or
> used the whole disk to create a FAT32 partition. The crucial bit is not to
> silently create the four logical partitions and also leave them unformatted.

> I suggest that there should be an option to let the user decide what to do
> between these two options or something else.

I really seldom do this, but +1

Tom



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

Re: [Freedos-user] DOSshell replacement

[tom ehlert]

> I am looking for a fairly simple, ideally text-only, app menu system.

https://www.horstmuc.de/ui.htm

'Dialog boxes for DOS batch:

menus, buttons, input fields, checkboxes, radio buttons, list selection

Easy handling, no ANSI stuff to deal with - colors are specified by name.
WBAT runs under all Windows versions or plain DOS.
 
Features:

Layout for box with text and control elements - all elements can be freely 
arranged
Quick box with specifications in the command line
Selection from batch generated lists (e.g. DIR file lists)
Text pages with color attributes
INI file with defaults and preferences
Win NT/2000 compatible handling of variables

Mouse handling is supported in a GUI box as well as in full screen mode. Of 
course WBAT will also work under plain DOS.
 
DEMO.BAT supplied with full handling details (instead of a DOC file).
'



Tom



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

Re: [Freedos-user] CP/M "and derivatives" legal status clarified

[tom ehlert]

> On the assumption that DR-DOS is included among the CP/M derivatives,
> which would agree with the fact that DRDOS, Inc. did sell DR-DOS 7.xx
> (and the shortlived DR-DOS 8.xx) and so had the rights to those, this
> means that EDR-DOS is now free!


that's a rather far fetched assumption.

DR-DOS is as much a CP/M derivative as Windows 11 is a derivative of
MSDOS 2.0

OTOH who cares if DR-DOS is more or less free? I don't see the
relevance.


Tom



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

Re: [Freedos-user] Keyboard issue (Fixed)

[tom ehlert]

> Nice response Tom.  Next time don’t be so shy and really let the
> language fly, but ya did have a good point if not good language.

well the original question

> > In DOS I was able to press and hold a key and the key would repeat.
> > Great for arrow and page keys.? For some reason this stopped workin

is proof of the fact that there ARE stupid questions. what kind of
response do you expect?



> 1) Real DOS on bare metal runnin msdos 7.1.  I have had this happen on 
> FreeDOS as well.
> 2) Config.sys and autoexec bat are the same and nothin there has changed.
> Fix:  The fix was a simple one yet quite odd, in my opinion. 
> Apparently while one keyboard will allow me to hold down a key and
> it repeats, another keyboard wasn’t allowing me to do it.  Not sure
> why that is.  I found out this was the issue when it was suggested I try 
> another keyboard.

you might have added to your original question:

I changed nothing except I changed the keyboard. for some reason this
stopped working.

Tom






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

Re: [Freedos-user] Keyboard issue

[tom ehlert]

> In DOS I was able to press and hold a key and the key would repeat.
> Great for arrow and page keys.  For some reason this stopped workin

wow. one of these Asshole from Hell questions:

no information what DOS we are talkink about.

no information whatsoever about CONFIG.SYS/AUTOEXEC.BAT.


good luck

Tom









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

Re: [Freedos-user] dev86

[tom ehlert]

Hallo Herr ZB,

am Montag, 30. Mai 2022 um 16:51 schrieben Sie:

> On Sun, May 29, 2022 at 11:34:18PM -0500, Jim Hall wrote:

>> But tkchia is listed as a contributor of dev86 tools, so maybe tkchia can
>> provide additional comments here.

> Yes, I mean exactly that package, and if somebody already compiled it for
> DOS, I'll just save some of my time trying to do that compilation

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


download zip.
unpack.
goto BIN directory.

Tom



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

Re: [Freedos-user] NDCONFIG.SYS

[tom ehlert]

> according to https://moddingwiki.shikadi.net/wiki/Microsoft_EXEPACK ,
> the EXEPACK option (which was a precursor to PKLITE, DIET, ... which
> were precursors to UPX) was available for MS link.exe (at least)
> in 1986. which doesn't make 2022 exactly 'modern times'.

according to the same website, and the cited alghorithm, MS EXEPACK was
simply run length encoding, so FDCONFIG.SYS and FDAUTO.BAT were
probably right there in the executable binary.

only DIET, PKLITE and friends used LZ77 compression. probably 1993 or
(slightly) later.

I should have known as the DrDOBBS compression contest was in 1992,
and LZ77 was not yet an (mostly) agreed upon standard.


Tom



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

Re: [Freedos-user] NDCONFIG.SYS

[tom ehlert]

Hi Robert,

 If you want to have FreeDOS look for NDCONFIG.SYS, you will need to edit
 the FreeDOS kernel source code and recompile. It does not look for
 NDCONFIG.SYS on its own.
>> 
>>> It maybe easier to use a hex editor on kernel.sys & command.com. ;-)
>>> Just my two cents ...
>> 
>>> Cheers,
>>> Robert
>> 
>> the kernel is UPX'ed (and can't be UPX -D 'ed); a hex editor will not work.
>> 
>> similar command.com, but this can be decompressed.
>> 
>> just MY two cents

> You're right. I "love" these modern times.

according to https://moddingwiki.shikadi.net/wiki/Microsoft_EXEPACK ,
the EXEPACK option (which was a precursor to PKLITE, DIET, ... which
were precursors to UPX) was available for MS link.exe (at least)
in 1986. which doesn't make 2022 exactly 'modern times'.

in addition, these early versions of EXEPACK were buggy (they assumed
that :0020 points to the same location as :0010), which lead
to problems when programs could be loaded into the 1'st 64K of memory.

it basically layed the foundation to the A20 gate being still around in
'modern times', and the existence of LOADFIX.

actually, the same bug plagued early versions of PKLITE. at least
later versions of PKLITE were able to unpack and repack the executable
and fix the bug.

Tom




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

Re: [Freedos-user] NDCONFIG.SYS

[tom ehlert]

Hallo Herr Robert Riebisch,

am Mittwoch, 18. Mai 2022 um 18:38 schrieben Sie:

> Hi Jim,

>> If you want to have FreeDOS look for NDCONFIG.SYS, you will need to edit
>> the FreeDOS kernel source code and recompile. It does not look for
>> NDCONFIG.SYS on its own.

> It maybe easier to use a hex editor on kernel.sys & command.com. ;-)
> Just my two cents ...

> Cheers,
> Robert

the kernel is UPX'ed (and can't be UPX -D 'ed); a hex editor will not work.

similar command.com, but this can be decompressed.

just MY two cents

Tom



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

Re: [Freedos-user] Shared folders in VirtualBox

[tom ehlert]

Hallo Herr Robert Riebisch,

am Dienstag, 26. April 2022 um 22:10 schrieben Sie:

> Hi Javier,

>> I have recently been working on making a VirtualBox shared folders
>> client/redirector. I tested it on FreeDOS 1.2 and it seems to work. 
>> 
>> See https://git.javispedro.com/cgit/vbados.git/about/

> I tested VBSF.EXE 0.54 on stock FreeDOS 1.3 and SvarDOS (uses an older
> FreeDOS kernel from 2016)

before reporting bugs, it would be a good idea to report with a recent
kernel (although I don't expect a difference).

>  and at first it seemed to work, but I found it
> not very stable. Trying to copy folders from DOS to the host led to
> errors about being unable to read the files from the source folder.

with both of your tries?

COPY? XCOPY? VC COPY?

does
  COPY C:*.* NUL
work? is that related to the destination being
remote?

of course 'errors' might have more meaningful messages other then
'error'.


> Additionally, I noticed timestamps are not correct. Most (?) times the
> date and time of the point in time of copying will be shown.

again, the name of the copiying program might be helpful.

> I also noticed on SvarDOS copied files will sometimes show up as type
> 'directory'. I'm unable to open these 'folder' with a text editor or
> change to them, but I could delete them with 'del filename'.

in a DOS environment (other then windows), most things are
reproducable. i.e. the same batch should always result in the same
results.so document your steps. usually in a .BAT file.

however your above 'my actions result in error' could be better.

Tom



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

Re: [Freedos-user] MKEYB 0.48 works on PC and XT machines.

[tom ehlert]

Hi Jerome,

>> On Apr 3, 2022, at 11:50 AM, tom ehlert  wrote:
>> 
>> Hi everybody,
>> 
>> mKEYB used to need AT class machines or better to work.
>> 
>> Davide Bresolin taught mKEYB to run on PC's and XT's.

I forgot to add:

WITHOUT increasing the resident footprint for AT+ class machines.

>> now he has a 700 byte keyboard driver, saving 2.3 KB wrt XKEYB
>> and 5 KB wrt. MS KEYB.
>> 
>> announcement 
>> https://forum.vcfed.org/index.php?threads/the-quest-for-a-small-keyboard-driver.1238141/
>> download https://github.com/davidebreso/mkeyb/releases/tag/v0.48
>> 
>> Tom

> Since this version is not on your page, I have some questions…

> Does it mean you are passing development off to Davide and I need
> change the package LSM to show it is maintained by him? Including
> the primary download site be changed to his GitHub repo along with maintained 
> at URL?

> Or, does it simple mean you plan on continuing development and I
> should just add such things to the LSM?

> Or, does it mean you plan on incorporating his changes and the metadata is 
> fine as it is now?

reasonable questions.

in the moment I'm not in reach of a DOS environment, so I am not able
to test his drivers. looking at his source changes, I am fairly
confident this should work (and of course he tested this himself).

as soon as I have tested this in my environment (not long), I plan to
incorporate his changes, and the metadata is fine as it is now.

Tom



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

[Freedos-user] MKEYB 0.48 works on PC and XT machines.

[tom ehlert]

Hi everybody,

mKEYB used to need AT class machines or better to work.

Davide Bresolin taught mKEYB to run on PC's and XT's.
now he has a 700 byte keyboard driver, saving 2.3 KB wrt XKEYB
and 5 KB wrt. MS KEYB.

announcement 
https://forum.vcfed.org/index.php?threads/the-quest-for-a-small-keyboard-driver.1238141/
download https://github.com/davidebreso/mkeyb/releases/tag/v0.48

Tom



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

Re: [Freedos-user] Documents; was Re (2): Installing freedos to virtualbox them copying dice contents to an actual computer

[tom ehlert]

>> A word processor understands what sentences and paragraphs are, ...

> HTML has the paragraph element,  ... , understood by a Web 
> browser. Reference the introduction of
> https://en.wikipedia.org/wiki/HTML .

*this* is the FreeDOS Email list. related to OS issues.


please have your 'whichever EDIT is best' somewhere else, in
particular when editing HTML5 (which is entirely irrelevant for
FreeDOS of any kind).


just have your 'best editor ever' wars somewhere else.

Tom



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

Re: [Freedos-user] Issue: FreeDOS on PCem emulating a NE2000

[tom ehlert]

Hallo Herr Brandon Taylor,

am Mittwoch, 16. März 2022 um 17:11 schrieben Sie:

> I've discovered a neat little low-level emulator called PCem and
> have installed FreeDOS on a virtual machine using that program.
> There is, however, a weird little quirk. Whereas I can have PCem
> emulate a network card such as an NE2000, and configure FDAUTO.BAT 
> to load high the appropriate packet driver (NE2000.COM), trying the
> next command -- "call %dosdir%\bin\fdnet.bat start" fails with the
> message "Physical hardware networking is not supported at this time."


>  Now, from what I've read in previous posts, it sounds like others
> have had success by replacing "start" with "try," such that the line
> now reads "call %dosdir%\bin\fdnet.bat try", so I tried that fix,
> but now I get another problem, saying "Error: Your DHCP  server
> never responded and no packets were seen on the wire. Check your
> cabling and packet driver settings, including the hardware IRQ.
> Network is unreachable/unavailable."


>  Inspired by the example provided in the FreeDOS Wiki (for a 3Com
> 3c589 PCMCIA card -- not important), I entered the following line into 
> FDAUTO.BAT:


>  lh %dosdir%\drivers\crynwr\ne2000.com 0x60 10 0x300


just test if dropping LH works better.


%dosdir%\drivers\crynwr\ne2000.com 0x60 10 0x300


loading programs in conventional memory often avoids problems; in
particular when these programs may or may not use DMA

Tom



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

Re: [Freedos-user] How to add AHCICD.sys in the auto check-list for USB BOOT?

[tom ehlert]

Hallo Herr richardkolacz...@hotmail.com,

am Freitag, 11. März 2022 um 17:23 schrieben Sie:

> I use the ONE USB BOOT stick for two laptops (only one has an optical drive).


>  I was able to recognize the optical drive by simply putting
> AHCICD.sys into the \FreeDOS\BIN\ folder (on the USB stick) and for
> the laptop with the optical drive, the system boots up nicely.


>  However, because I want to use the ONE USB stick for both
> machines, now on the second laptop (without optical drive), on
> bootup, the computer locks up at the AHCICD.sys stage. When the
> AHCICD.sys file is simply removed, the usual FreeDOS checking on 4
> CD possibilities  "errors out" in a controlled manner and allows continuation 
> of the BOOT-up.


>  So how can I have this 5th CD check (i.e. checking via AHCICD.sys)
> in the manner of the 4 CD checks already in FreeDOS.

load it like

?device=AHCIDD.SYS

will ask you if it shall be loaded.

Tom







> Richard



> From: Robert Riebisch 
> Sent: Friday, 11 March 2022 7:25 PM
> To: Discussion and general questions about FreeDOS.
> 
> Subject: Re: [Freedos-user] retro gamer review of FreeDOS 1.3
>  
> Hi Jim,

 >> One program to fix the "runtime error 200" is Robert and Marek's TSR
 >> tool, which we include in FreeDOS 1.3:
 >>  
 >> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/tp7p5fix.html

>  Robert here. I noticed, TP7P5FIX is not working for all software, but I
>  didn't investigate this.

>  I had good results with
>  <http://kannegieser.net/veit/programm/r200fix.arj>. (Sources:
>  <http://kannegieser.net/veit/quelle/r200fix_src.arj>)

>  Cheers,
>  Robert
>  -- 
>+++ BTTR Software +++
>   Home page: https://www.bttr-software.de/
>  DOS ain't dead: https://www.bttr-software.de/forum/


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





Mit freundlichen Grüßen / with kind regards
Tom Ehlert
+49-15151898538



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

Re: [Freedos-user] I never saw one

[tom ehlert]

Hallo Herr Jose Senna,

am Mittwoch, 9. März 2022 um 19:56 schrieben Sie:

> Eric Auer said:
>> I would certainly prefer manual
>> partitioning over autocreated
>> FAT16 C: to ZZZ9: drives of which
>> only C: gets formatted anyway ;-)

> Is it possible to have a ZZZ9: drive
>  in DOS (or other many letter ID) ?


unlikely. some DOSes allowed 0x40..0x59
ie A..Z + @[]\^


but none allowed anything other then x:

Tom



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

Re: [Freedos-user] Looking for easy to follow instructions on how to connect to Samba share

[tom ehlert]

>> > Concurrent access to files is something already handled by SHARE

>> SHARE is all about access to *local* files, on the FreeDOS machine, and
>> has absolutely nothing to do with sharing remote files.



> MSCLIENT uses SHARE as well, it complains if you don't have it loaded.

if you use it as a SERVER.

Tom





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

Re: [Freedos-user] Will freedos running in a Virtual box VM recognise a host attached USB security dongle?

[tom ehlert]

Hello,


> Before I loose hours trying to get this to work this weekend. Would
> anyone know about getting freedos to recognize USB security dongles?

that's easy: ANYDOS does nothing about USB, and neither USB security
dongles.



> I use a HASP USB security dongle to activate an old software
> program. I want to run that program from FreeDOS running in a
> Virtualbox VM.

does it run from MSDOS on real hardware?
does it run from FreeDOS on real hardware?

only then should you start to try things in a VM (of whatever kind).


> Lets say I connect the USB dongle to my Win 10 host that is running
> the VM. Will the FreeDOS OS (or the OS could maybe be Win 7 instead)
> running in the VM be able to see that HASP USB security dongle and
> the program running in that VM get activated for use?

how about asking this to product support; either HASP or the
originating company?





> From my reading it can be done in Virtualbox

VirtualBox can indeed forward USB devices to the VM. if this is
compatible enough to run *cryptic* dongles should be a question to
HASP, not us.

> but not sure if
> freedos will recognize the usb drivers
'the usb drivers'?

you could have tried this by now.

Bye.

Tom






> or would I need to install
> them in the guest as well as the host which will be Win 10.


> Cheers,


> Sean

> On Fri 4 Mar 2022, 11:54 tom ehlert,  wrote:



 >>> I was referring to the recommendation of using a "folder" as a drive under
 >>> DOSEMU.  I don't believe that solution supports multiple node access to the
 >>> same folder.
 >>> 
 >>> SMB (i.e. MSCLIENT and Samba) were designed for this use case.

 >> What makes you think so?

>  Just because it's true? in MSDOS at least.
>  However I have no idea if that is even implemented in FreeDOS, or
>  DOSEMU.

 >> Concurrent access to files is something already handled by SHARE
>  SHARE is all about access to *local* files, on the FreeDOS machine, and
>  has absolutely nothing to do with sharing remote files.


>  Tom



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






Mit freundlichen Grüßen / with kind regards
Tom Ehlert
+49-15151898538



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

Re: [Freedos-user] Looking for easy to follow instructions on how to connect to Samba share

[tom ehlert]

>> I was referring to the recommendation of using a "folder" as a drive under
>> DOSEMU.  I don't believe that solution supports multiple node access to the
>> same folder.
>> 
>> SMB (i.e. MSCLIENT and Samba) were designed for this use case.

> What makes you think so?

Just because it's true? in MSDOS at least.
However I have no idea if that is even implemented in FreeDOS, or
DOSEMU.

> Concurrent access to files is something already handled by SHARE
SHARE is all about access to *local* files, on the FreeDOS machine, and
has absolutely nothing to do with sharing remote files.


Tom



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

Re: [Freedos-user] ECHO vs @ECHO

[tom ehlert]

Liam,

> On Tue, 1 Mar 2022 at 20:02, Bret Johnson  wrote:
>>
>> Actually, no it's not.  It's fairly easy with System Commander.  And AFAIK, 
>> System Commander is the only multi-boot manager that works this way 
>> (manipulating the boot files instead of manipulating disks or partitions).  
>> Both approaches have advantages and disadvantages.

> That's not the point here.

> Can you roll back changes? Can you make a snapshop of one system and
> then revert to it? Can you duplicate a system and send it to someone?
> Can you keep backups of just one system? Can you store backups on a
> server or a removable drive?

> All those are trivially easy with VMs.

just about everything above is close to trivial. this is DOS, and
XCOPY (or ZIP) will do all of the above.

now YOU explain to the rest of the world how to keep all the different
systems synchronised. given that there will never be a direct
communication between different VMs. fixing a program requires synching
this for multiple VMs.

VMs are very useful, and Bret's approach might even be to a *single*
virtual machine.

but Bret's problem is to have ONE program (and possibly one batch file) to
be tested against multiple OS versions without too much fuss.

your approach doesn't help at this. just shut up.

Tom



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

Re: [Freedos-user] ECHO vs @ECHO

[tom ehlert]

> if I wrote
> anything I think it would be something that actually tries to
> manipulate the ECHO state (if that's even possible without a WHOLE lot of 
> work).

1'st) you still get the output of your

  ECHOSTATE OFF

program on screen, which started the whole discussion.

2'nd) there is no ECHO state variable, other then a local variable for
each version and release of command. forget it.


> But, I still think this provided an interesting discussion and
> generated some good ideas people may be able to use in other
> situations.  I definitely found it interesting how the different DOS
> versions handle something as seemingly benign as processing the ECHO command 
> in batch files.

> I'll probably end up just learning to live with the screen clutter and leave 
> it at that.

I'm still surprised the

   ECHO Off | VGoToXY Up | VEcho /N /E

line doesn't work, but as I don't care about MSDOS 3.x anyway I will
be able to live with that

Tom



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

Re: [Freedos-user] ECHO vs @ECHO

[tom ehlert]

>> Multi-booting all those OSes off a single partition is very *VERY*
>> much a hard way of doing this.

> Actually, no it's not.  It's fairly easy with System Commander.
+1

while I didn't use System Commander, *ALL* of us were booting multiple
systems from the same disk (and possibly also partition) in 'the good
old times (tm)'. it was just a problem to be solved, and all of us
solved it one way or the other. no rocket science necessary.

VHD's simply weren't an option. VHD's came 15 years later.

>> VirtualBox is free. It runs DOS with aplomb. You could run all these
>> DOS versions in separate VMs, with no overlap, and custom config
>> files.

> As are QEMU, BOCHS, PCem, etc.  All the VM's have advantages and
> disadvantages in various respects.  The way I have my system set up
> I only need one VHD and it will work with (almost) any VM, including
> VirtualBox, and a bunch of different versions of DOS.  In terms of
> the amount of work it takes to set things up, I think my setup is
> less work than creating 20 (or whatever) different VHDs (each for a
> different OS).  My setup is definitely less work than trying to
> track and maintain all the different VHDs to make sure they remain consistent 
> with each other.

+1

>> You could have a separate D: drive on a separate virtual disk, with
>> the programs you're testing in it.

> That's what I do now (or at least can do if I want).  But, I can
> also put the test program on the common VHD if I want instead of a
> separate VHD (and if it's small enough I usually do that).  With
> your setup it MUST be on a separate VHD or I would need to copy it
> 50 (or whatever) times instead of just once.  So, my setup is more flexible 
> in that sense.

>> Or you could use VMWare Server, which is freeware, and in which this
>> is a built-in facility.

> In addition to the VMs mentioned above, I also have others
> including VMWare and DOSBox and do tests with all of them.  VMWare
> and DOSBox are somewhat unique in that they can mount physical hard
> drives instead of just virtual hard drives.  That allows you to have
> similar setups in both a VM and on the real hardware (if you boot
> the real hardware to DOS, which I also sometimes do).

> There are lots of different ways to "skin the cat" and there is not
> one "correct" way.  There are tradeoffs and problems with every
> approach.  But, for what I'm trying to accomplish, I think my setup
> is better (at least easier to track and maintain) than what you're 
> recommending.

+1

Tom



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

Re: [Freedos-user] ECHO vs @ECHO

[tom ehlert]

Bret,


> 3.  Just let the problem happen and "fix" the screen afterwords

Jerome's approach is probably the only sensible solution,
like

>> echo off | vgotoxy up | vecho /n /e

> This to me seems like a solution that could actually do what I'm
> wanting to accomplish.  I may experiment with that and see what
> happens.  As you note, there may be compatibility issues with some
> DOS versions (V8 power tools may not work with older versions of DOS).

very unlikely. besides that, writing a utility

   get cursor position,
   subtract one,
   set cursor position,
   output " \r"
   exit

is left as an exercise to the reader(s).


> With batch files, including AUTOEXEC.BAT, the default is "ECHO ON",
> which is backwards from what CONFIG.SYS does.  Anyway, I was
> wondering if it might not be a good idea in a future version of
> FreeDOS to have something like a "BATCHECHO=OFF/ON" and
> "CONFIGECHO=OFF/ON" setting (probably in CONFIG.SYS) to set the
> default ECHO values for those, and maybe have the "@" do the
> opposite of what it does now when ECHO=OFF (display a line instead
> of hide it).  Just a thought (maybe a stupid one).  

this would 'solve' the problem for future FreeDOS/FreeCOM
versions ONLY. however FreeCOM has the well known @ECHO OFF
feature to begin with ;)

Tom



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

Re: [Freedos-user] ECHO vs @ECHO

[tom ehlert]

>> in addition, neither I nor you know if 'CTTY NUL' works on MSDOS 3.0

> The original requirement was MSDOS <3.30.
> I tested with MSDOS 3.21 and it worked.

> Test with MSDOS 3.0 was okay too.

correcting myself, CTTY NUL probably always worked, from MSDOS 1.0,
as MSDOS was supposed (I never tested) to be able to run on a serial
terminal.

so

   CTTY COM1

would redirect input and output to COM1. and you could move the cursor
on the screen (and other stuff) using ESCape sequences. ANSI.SYS was used
to simulate this (I think a VT100 terminal) on the CGA display, so
software could be written that would work 'everywhere'.

Tom





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

Re: [Freedos-user] ECHO vs @ECHO

[tom ehlert]

Hallo Herr Bob Pryor,

am Sonntag, 27. Februar 2022 um 06:44 schrieben Sie:

> Once you have debugged ALL your batch files you can place `CTTY
> NUL' before the command(s) and `CTTY CON' after to avoid output to screen.


excellent idea.

now you have exchanged the annoying

  echo off

for the much better

  CTTY NUL


in addition, neither I nor you know if 'CTTY NUL' works on MSDOS 3.0

Tom



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

Re: [Freedos-user] ECHO vs @ECHO

[tom ehlert]

Hallo Herr Mercury Thirteen via Freedos-user,

am Samstag, 26. Februar 2022 um 03:47 schrieben Sie:

> Would it be feasible to throw together an "@ECHO.COM" application
> which would manually execute a normal "ECHO OFF" line if the DOS
> version is below 3.3 and simply terminate otherwise? The only caveat
> to this is that I''m not 100% certain

just because this is complete nonsense?

Tom



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

Re: [Freedos-user] DOSHEXED - memory bug

[tom ehlert]

Hallo Herr Mateusz Viste,

am Samstag, 19. Februar 2022 um 15:08 schrieben Sie:

> On 12/01/2022 18:22, tom ehlert wrote:
>>> You might want to try uHex. Requires some 20 KiB of RAM and handles
>>> files up to 2 GiB.
>> 
>> use int 21, 6C EXTENDED OPEN/CREATE and you can handle 4GiB.

> This does not appear to be present in the FreeDOS kernel. Or at least 
> the source code comment says "not implemented yet" (and the O_LARGEFILE
> flag does not appear to be used anywhere later in the code):

> https://github.com/FDOS/kernel/blob/master/kernel/dosfns.c#L498

OOPS.

I hadn't thougt about this as the FreeDOS kernel (AFAIK) doesn't
check for offsets beyond 2GB.



> Do you have a FreeDOS kernel version that supports this?
most likely no ;)

Tom



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

Re: [Freedos-user] Difficulty with serial communications

[tom ehlert]

Hallo Herr Travis Siegel,

am Donnerstag, 10. Februar 2022 um 13:15 schrieben Sie:

> https://forums.raspberrypi.com/viewtopic.php?t=234228

even if true, here is the wrong place to discuss.

just in case you didn't notice: this here is a forum about FreeDOS,
possibly other DOS in general, but definitively not about Raspberry PI.

can we please stop this thread.

Tom



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

Re: [Freedos-user] Difficulty with serial communications

[tom ehlert]

> as you have a linux version of your program, I wonder why you insist
>> on running on DOS.

> A number of reasons, as I said.  The main reasons are not technical.

> Of course something along those lines would be technically feasible,
> but in some cases it isn't an option.

as you don't indicate your reasons, or indication why it's not an option:

good luck. and bye.

Tom



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

Re: [Freedos-user] Difficulty with serial communications

[tom ehlert]

Hi,

as you have a linux version of your program, I wonder why you insist
on running on DOS. just run your program on a dedicated machine, don't
ever connect it to the any net or WLAN, never update it, and you have
the functional equivalent of a DOS machine.

as a bonus, this even avoids problems with UEFI-only machines in the
future.


Tom



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

Re: [Freedos-user] Difficulty with serial communications

[tom ehlert]

Hi,
> The multi-port cards I've used in the past have been ISA.  I did have
> to modify some of them to share interrupts, but that's always worked
> OK.  Of course these won't fit in most recent computers.  Multi-port
> PCI cards I've seen handle interrupt and I/O addressing differently
> from the way the ISA cards did it.  I/O addresses are no problem, any
> address is configurable in the software, but despite claims to be able
> to use IRQ3 and IRQ4 in the sales literature none of the PCI cards
> that I've tried so far appears to be able to use either.

some warnings first: my (extensive) experience with COMx is ~23 years
old, so I may be wrong.

expect COM1234 to be located on 0x3f8,2f8,3e8,2e8  (as indicated at 0x40:10)
expect interrupts 3,4,3,4

https://de.wikipedia.org/wiki/Interrupt says
3   COM 2, 4, 6, 8 (EIA-232/RS-232)
4   COM 1, 3, 5, 7

for the obvious question where COM5678 have their ports, you have to
consult PCISCAN utilities, or the wider internet...

only if that doesn't work, dig deeper.

> My software
> expects that only those will be used for serial comms (if you think
> that means the software is silly, I'd blushingly have to agree).
even in hindsight, I *think* even today only 3 and 4 are used.

it might be useful to install linux, windows, or whatever on a
machine with such a multi-port adapter and use
settings->devices->COM5->properties to investigate this.


> At some point I'd like to modify the software to handle more recent
> hardware but it's a long time since I did all that and I've almost
> forgotten how it all hangs together.
+1

tom



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

Re: [Freedos-user] Cutemouse /O OR keeping your source code secure

[tom ehlert]

>  Also,
> through a series of unfortunate hard-drive problems and corruptions,
> I managed to lose the source code for MOUSKEYS.  So, in order to
> "upgrade" MOUSKEYS to support wheels, I would need to start by
> recreating it from scratch again (basically, I would need to
> reverse-engineer my own program since I lost the source code).

a) in germany we have a saying "Kein Backup, kein Mitleid" which
translates roughly to "no backup, no pity"

b) one of the advantages of open source software is that you have
automatically backups on a bazillion of computers.

Tom



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

Re: [Freedos-user] DOSHEXED - memory bug

[tom ehlert]

> On 12/01/2022 14:58, Michał Dec wrote:
>> Is there any other hex editor for FreeDOS

> You might want to try uHex. Requires some 20 KiB of RAM and handles 
> files up to 2 GiB.

use int 21, 6C EXTENDED OPEN/CREATE and you can handle 4GiB.



> IIRC it is shipped with FreeDOS, but if not then you will find it here:
> http://uhex.sourceforge.net/

> Mateusz

Tom



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

Re: [Freedos-user] Country Code

[tom ehlert]

> At that point, the system wants to create a page file that is larger (by
> default) than the 2GB fixed file size limit of FAT16/32.

FAT has a limit of 4GB.

it's DOS that limits this unless you indicate at DosOpen that you understand
the difference between signed and unsigned (2GB and 4GB) offsets for
file systems. so the limit for NT was 4GB, not 2 GB (or at least
should have been)

Tom



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

Re: [Freedos-user] Video complains that DOS should not be maintained

[tom ehlert]

> If Microsoft did not do it, imagine how nice it would be that there
> were in FreeDOS an open source version of VMM32 with a good set of
> well written VxDs  (and that the very first thing it does after
> loading is NOT to find that KRNL386.EXE and run it). Of course,
> that's an outstanding challenge, I don't think anyone would do it :(

even assuming

a) we have a well written design of 'a good set of well written VxDs'

b) lots of highly qualified programmers that would turn this design
into well written code, thereby wasting many years of precious life
time

what exactly do you think would happen? there are no programs around
that would do anything useful with these wonderful VXDs. and now the
life time is really wasted ;)


the problem here is that a multitasking DOS (like OS/2 1.9) is much more work
by an order of magnitude, and nobody around FreeDOS is doing any reasonable
programming work (with the possible exception of Ercsan, and he is not
qualified).

can we please close this issue?




Tom



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

Re: [Freedos-user] Video complains that DOS should not be maintained

[tom ehlert]

> Well, as said above, this has precisely been proved to be extracted
> from Windows and used for stand-alone DOS environment. Just because
> it is called VMM32.VXD (and not the original DOS386.EXE name), and
> has been sold just with Windows, and not DOS, does not mean it is an 
> un-dettachable part of Windows. 
> To the same extent that if HIMEM hadn't ever been sold with MS-DOS,
> does not mean it is not an extension of DOS.

the easiest way to have a multitasking 'DOS' is LiLo.

Tom



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

Re: [Freedos-user] Video complains that DOS should not be maintained

[tom ehlert]

>> while technically true, it couldn't just multitask ramdom DOS programs
>> as multi tasking systems like OS/2 or better always could.

> Yes, it can. I have tested it with, for example, the MS-DOS Editor
> from Windows 98SE on one screen, WordPerfect 6.2 on another screen and
> MS Word 6 on a third screen.
I have to accept that as true. Though 'multiscreening' is not what
everybody thinks of when thinknig 'multitasking'.

however DesqView, GEM and Windows 3.x are certainly multitasking systems
running on top of DOS. that doesn't make DOS a multitaskig system.

>> programs would only multitask if specifically written to the DRDOS API
>> - which almost nobody did (for commercial avalable software).

> This is not true.
ou might be right, but I would be surprised.



>> that is true. the (mostly) complete source code MSDOS 6.2 escaped into the 
>> wild,
>> even if not widely available.

> You said, quote:

>> > it wasn't a sanctioned release from microsoft.

> Don't try to revise this now.

I have no idea what you are arguing about.

MSDOS 6.2x sources went into the wide plains of the internet, and
probably are still available now in public. Just don't expect to have
google to turn up sensible sources for 'msdos 6.21 source code'

And this is completely irrelevant in 2021, or forever (except for historical
reasons).

beside this: everybody a nice christmas and a happy new year!


Tom










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

Re: [Freedos-user] Video complains that DOS should not be maintained

[tom ehlert]

>> That was caldera that released their opendos  as opensource, not Microsoft.

> Caldera released Digital Research's DR DOS 7.01 as FOSS. It then
> changed its mind and made v7.092 closed-source again, but 7.01 remains
> FOSS and turned into OpenDOS, AKA DR OpenDOS and Open DR DOS.

> And, for what it's worth, DR DOS has multitasking, and I've tried it,
> and it works.

while technically true, it couldn't just multitask ramdom DOS programs
as multi tasking systems like OS/2 or better always could.

programs would only multitask if specifically written to the DRDOS API
- which almost nobody did (for commercial avalable software).

>> There were versions of ms dos that escaped into the wild, but it wasn't
>> a sanctioned release from microsoft.

> This is not true.

that is true. the (mostly) complete source code MSDOS 6.2 escaped into the wild,
even if not widely available.

> Microsoft has released MS-DOS 1.25, 2.0 and 2.11 as FOSS.

> The OS/2 Museum have rebuilt it from source:

> https://www.os2museum.com/wp/pc-dos-1-1-from-scratch/

> https://www.os2museum.com/wp/dos-2-11-from-scratch/

MSDOS 2.11 might be interesting from a museum/historic prespective.
as an operating system it's completely obsolete and useless, and you will not 
learn
much by studying the source code.

there's a LOT that happened between 2.11 (october 1983) and 6.22 (april 1994)

Tom



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

Re: [Freedos-user] FreeDOS and LFN

[tom ehlert]

> LFN are for Unix programs (DJGPP). DOS programs, like dir, do not know
> about them.

FreeDOS command has support for LFN dir since ~15 years.

use
   DIR /LFN

for this, or
  set DIRCMD=/LFN

the most recent command has LFN support almost everywhere, like in
COPY, DEL, redirection and more

Tom



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

Re: [Freedos-user] How to build FreeCom on open watcom

[tom ehlert]

Hallo Herr saito yutaka,

am Sonntag, 5. Dezember 2021 um 13:22 schrieben Sie:

> Hello.




> I get a error when memory model is unchange.
> Compile fixstrs.c is failed.［1］

fixstrs.c is compiled using  STRINGS.MAK, and references
FIXSTRS_MMODEL.

good luck.

Tom





> ［1］
> https://github.com/FDOS/freecom/blob/master/strings/fixstrs.c#L162


> Thanks.
> 2021年12月5日(日) 20:26 TK Chia :

> Good day saito yutaka,

 >> I modified config.mak as follow.
 >> Other settings are same as config.std[1].
 >>
 >> ---
 >> ## Memory model of FreeCOM
 >> !if $(DEBUG)0 == 10
 >> SHELL_MMODEL=l
 >> DEBUG=-DDEBUG
 >> !else
 >> SHELL_MMODEL=l
 >> DEBUG=-UDEBUG -DNDEBUG
 >> !endif
 >> SHELL_MMODEL_COMP=$(SHELL_MMODEL)

>  Unfortunately, in general, you cannot simply change a MS-DOS program's
>  memory model from "medium" to "large" willy-nilly --- especially when
>  the program contains assembly language (.asm) modules.  That simply does
>  not work.  The compiled output binary will not behave correctly.

>  Microsoft's blog has a bit of an explanation on what the various 16-bit
>  memory models (tiny, small, medium, compact, large, huge) mean:

> https://devblogs.microsoft.com/oldnewthing/20200728-00/?p=104012

>  Hope the above helps.

>  Thank you!

>  --
> https://gitlab.com/tkchia :: https://github.com/tkchia


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






Mit freundlichen Grüßen / with kind regards
Tom Ehlert
+49-15151898538



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

Re: [Freedos-user] How to build FreeCom on open watcom

[tom ehlert]

Hallo Herr saito yutaka,


> Assertion Failed: p && !isoption(p) && !isspace(*p), function
> initialize, file init.c, line 371.

> I have no idea that why fail on initialize function.
> Where should I check ?

changing memory model requires some expertise, is highly unlikely to
succeed on first try.

try sprinkling printf() statements, or get a debugger.

Tom



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

Re: [Freedos-user] Enhanced Hangman EN_COMPS.VOC

[tom ehlert]

> I
> doubt this stuff is of much interest to the readers of this list. :)

exactly.

Tom



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

Re: [Freedos-user] FreeDOS game compatibility mass testing results/questions

[tom ehlert]

> That's not to say that FreeDOS is perfect. For the life of me, I
> cannot get the Wolfenstein 3D installer (1wolf14.zip) to run on
> FreeDOS. Even with nothing loaded, INSTALL.EXE aborts with "Runtime error 200 
> at 0774:0091"


"For the life of me" ...  "Runtime error 200"

which is a REALLY well known bug in the Turbo Pascal runtime library.
with a KNOWN fix, that was rejected by the freedos licensing experts.


google says "


Nicht schon wieder: Runtime Error 200 | c't Magazin - Heise
https://www.heise.de › ... › Tipps & Tricks
08.04.2000 — Mit dieser Meldung verweigern DOS-Programme auf schnelleren 
PC-Systemen ihren Dienst, wenn sie mit Borland-Pascal kompiliert worden sind.

Rechner zu schnell f. Programm "Runtime Error 200""

I wont claim I saved your life, but it would be cool to google before
posting uninformed stuff.

Tom



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

Re: [Freedos-user] FreeDOS game compatibility mass testing results/questions

[tom ehlert]

> I think that's a very narrow view. The reality is that a lot of the
> "classic" (say, '486 or earlier) hardware is hard to find - at least
> in working condition. And dedicating an entire machine to FreeDOS .
> So most people run FreeDOS on modern hardware (if they dedicate
> hardware to it at all) or in a virtual machine (more common). 

FreeDOS (and MSDOS) kernel and command are in no way hardware
dependent; exclude them from bug searching if just every game fails.
single failure might be possible, but not *every* game.

there are 2, more or less, 'hardware' dependencies:

HIMEM  tries to find out how much and where memory exists.

(J)EMM386 tries to find where are regions in A-F occupied by
hardware; and often enough got this wrong (not counting the bazillions
of times where it got it right as these cases are not reported on the
internet;).

it might be the BIOS reporting available memory above 1MB in a strange way,
misunderstood by  HIMEM/EMM386, leading to trouble.

or it might be EMM386 misunderstanding some adapter memory
requirements in the a000-f000 region.

just my 5 cents.

crossposting this to bttr-software.

Tom



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

Re: [Freedos-user] fdbox version v0.0.1

[tom ehlert]

Hi Diego,

> I releasing the first version of fdbox, a new shell for MSDOS/freeDOS,
> aka command.com. This is a very initial release, most of the features
> are semi broken, or work in progress. But the very basic code is there
> (you can dir, cd and execute applications).

Could you please explain why you think this is relevant?
Any fancy feature that FreeCOM is missing?
Anything that FDBOX is doing better?

We have an existing COMMAND.COM, with no (known) problems that your FDBOX
would solve.


> The code is available https://github.com/elcuco/fdbox, direct release
> to version 0.0.1: https://github.com/elcuco/fdbox/releases/tag/v0.0.1

so a 0.0.1 (most of the features are semi broken) 'release' shouldn't
be released unless it shows progress in some way.
unless you show something NEW. which you did not.


> Have fun and continue hacking!

sure.

Tom





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

Re: [Freedos-user] How to build FreeDOS kernel on FreeDOS

[tom ehlert]

>         C:\DEVEL\OW\BINW\WLINK.EXE @KWC38632.lnk;
> Open Watcom Linker Version 1.9
> Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
> Source code is available under the Sybase Open Watcom Public License.
> See http://www.openwatcom.org/ for details.
> Error! E3033: file KWC38632.lnk;: line(1): directive error near 'kernel.obj'
> Error(E42): Last command making (kernel.exe) returned a bad status
> Error(E02): Make execution terminated
> Compilation was aborted!
C:\SRC\KERNEL>>

only really bad people don't send  KWC38632.lnk after getting this
error.

maybe you try a different project?

Tom



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

Re: [Freedos-user] How to build FreeDOS kernel on FreeDOS

[tom ehlert]

Hallo Herr saito yutaka,

am Mittwoch, 27. Oktober 2021 um 12:16 schrieben Sie:

> Hi all.


> Thanks for your reply.


> I tried to build using OpenWatcom but error occurred when link.


> I used Config.bat as shown below [1].
> The output from the build is shown below[2].


> Is there something wrong in Config.bat?
yes. 


> Thanks
> Saito yutaka






> [1]
> :-  NOTICE!  You must edit and rename this file to CONFIG.BAT!   *
> :- determine your compiler settings
> :-
> :-


> set XNASM=nasm


> :- Watcom C
> set COMPILER=WATCOM


> :- if WATCOM maybe you need to set your WATCOM environment variables
> :- and path
> :- if not \%WATCOM% == \ goto watcom_defined
> set WATCOM=c:\DEVEL\OW
> set PATH=%PATH%;%WATCOM%\binw
> :watcom_defined


> set XUPX=upx --8086 --best
> :- or use set XUPX=
> :- if you don't want to use it




> :- Turbo Link
> :- set XLINK=tlink /m/c/s/l
> :- Microsoft Link
> :- set XLINK=d:\qb\link /ma
> :- set XLINK=%MS_BASE%\bin\link /ONERROR:NOEXE /ma /nologo
> :- set XLINK=%MS_BASE%\bin\link /ONERROR:NOEXE /ma /nologo
> :- WATCOM Link (wlinker is a batch file calling ms2wlink and wlink)
> set XLINK=C:\DEVEL\OW\BINW\WLINK.EXE /ma /nologo
set XLINK=C:\DEVEL\OW\BINW\WLINK.EXE  /nologo

Tom




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

Re: [Freedos-user] MKEYB related stuff

[tom ehlert]

Hallo Herr Mateusz Viste,

am Mittwoch, 13. Oktober 2021 um 09:15 schrieben Sie:

> On 12/10/2021 22:49, E. Auer wrote:
>> So at the risk of repeating the obvious: While it is possible to
>> construct some problems to justify your desired powerful solution,
>> this feels extremely over-designed from my view as Non-US DOS user.

> As far as I understand, this is not about designing some new solution to
> a possibly rare situation. This is about mimicking what MS did already
> 40 years ago... Isn't that the primary objective of FreeDOS?

I'm 100% certain that MSDOS didn't generate € characters in any
codepage. this should end the story of €'s.


>> If you want to address a REAL problem in FreeDOS

> Now, about "real" problems: it's highly subjective. You may find the
> 2GB-limit thing to be a problem - I don't. I'd say that if there's is 
> one problem with FreeDOS to pick up, it is COMMAND.COM's memory 
> footprint: it is *huge*. On my current setup, COMMAND.COM takes up 76K
> of RAM. That's 30% of the total memory on this machine... MS-DOS has the
> ability to swap out COMMAND.COM at runtime, so it takes roughly 5K (as
> per MEM/C output).

1'st: 'problems' is the plural of problem. 1 person running a single
museum 256K computer and insisting on using a 21'st century OS is
still just 1 problem.


2'nd: your machine is perfectly fine with the software that it came
with: MSDOS 1.0 or maybe 2.x

3'd: use the non-XMS-SWAP version of FreeCOM. it does exist, and is
supposed to swap to/from disk (I never tried). case dismissed.

Tom



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

Re: [Freedos-user] MKEYB related stuff

[tom ehlert]

>> under
>> what circumstances this is relevant so we can reproduce the problem
>> and it's solution.

> We've already showed you the problem and how to fix it.  With
> MKEYB, the Euro character is not generated correctly unless the Code
> Page is one where the Euro symbol is ASCII 213.  This is true for
> some Code Pages but not others.  That's a problem which you can
> easily reproduce yourself.  The solution is for MKEYB to be aware of
> the current Code Page instead of ignoring it,

how would MKEYB detect that code point 213 represents dotless i or €,
or what the correct code point for € is in the new selected codepage?
and how about äÄáàâÁÀÂ?


>  or at least warning
> the user that if they use the wrong Code Page some things may be displayed 
> incorrectly.

a pop up messagen Box "you have choosen to change the codepage, so €
no longer looks like €" ?

in fact MKEYB already warns the user by showing a  ı if the wrong
codepage is selected.

in fact an american who has never seen an international US-ASCII
keyboard (or even an Euro note) is probably not the right person to
argue here.

Tom



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

Re: [Freedos-user] MKEYB related stuff

[tom ehlert]

Hallo Herr Aitor Santamaría,

am Samstag, 9. Oktober 2021 um 19:01 schrieben Sie:


 >>> codepage is a display thing, essentially it's the table how to
 >>> convert 8-bit bytes into a visable character set, and mostly
 >>> unrelated to the way the keyboard driver converts scancodes into
 >>> bytes.

 >> The Code Page and the Keyboard layout are not unrelated at all -- -- they 
 >> are HIGHLY related.

>  nope.


> I'm afraid they are. Because when a user presses the key (or key
> combination) to produce Á, what the user expects is to see Á on the
> screen, and not just send a scancode where you may or may not be

send a keyboard code Á

> able to see Á depending if you are lucky with the codepage.
> And that's why the aforementioned door from DISPLAY to KEYB goes:
> the actual "intelligence" for that is in KEYB, not in DISPLAY. 

do you suggest to change the codepage if a user hits Á ?
if yes, does FD-KEYB do this? on what conditions?
does it make sure that all characters on screen (which were typed
before and looked ok) still look ok after codepage change?

actually, even accepting your argument (that I don't) that hitting €
should either automatically switch to the best loaded codepage with
'€' available, or be supressed (as Bret suggests), how is a keyboard
driver supposed to be able to determine if there is a proper display
representation for '€' at whatever 'ASCII' position?

> The key stuff here (what you were wondering about) is whether the
> user may want to switch the codepage (not the keyboard layout)
> dynamically or not. Because if you don't (as maybe the case in
> Germany, or Spain), MKEYB will suffice, but if you do, then you need
> this dynamic codepage switch on keyboard that MKEYB does not implement 
> (afaik).
it doesn't. Does FD-KEYB?
if so, on what conditions (as explained above)?



> I myself find a good reason to be able to issue a hot switch
> codepage: there used to be some dumb ancient programs that
> implemented a TUI that was heavy cp-437 dependent: they used to mix
> bix characters that mixed single-lined, and double-lined borders,
> which is NOT available in 850/858. They actually looked horrible
> under 850/858, and you may want to sacrifice the extended european
> symbols (such as Á) in order to have a better viewing of those programs.

you are right. Norton Commander and friends look horrible in codepages
different from 437. but this should be the problem of Norton (who
wants to display something), not the keyboard driver.




> When will the hot codepage change happen? The preferred way: the
> user issues a CHCP DOS call and NLSFUNC is loaded.
so not a keyboard driver problem.

>  Another popular,
> memory saving, but inconsistent manner: issue a MODE CON CP SELECT.  
not a keyboard driver problem either.


> How often will this happen? I suggest to look at the sources of
> KEYBOARD.SYS. Henrique used to implement lots of lots of different
> codepages for the same keyboard distribution. I guess in many of
> such cases, a hot codepage switch would be a popular issue.
just try to explain what,why and how Henrique tried this. and under
what circumstances this is relevant so we can reproduce the problem
and it's solution.

Tom



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

Re: [Freedos-user] MKEYB related stuff

[tom ehlert]

Hallo Herr Bret Johnson,


> So you made up your own GR mapping that is different than everybody
> else's (there is a "Tom's custom GR keyboard layout")?
of course not.

> Going back to the KEYB - Code Page relationship, I just ran a
> little "Euro test" to see how MEKYB and FD-KEYB handle the Euro
> symbol with Code Pages 437, 850, and 858.  At least in modern KEYB
> drivers, you are supposed to be able to generate the Euro key using
> AltGr-E.  Of course, Code Pages 437 and 850 don't have the Euro
> symbol at all (they were both invented before the Euro symbol even
> existed), but Code Page 858 does.  With MKEYB GR loaded, you can't
> generate a Euro symbol with AltGr-E no matter what Code Page is
> installed.

that's true(and a bug). for whatever reason MKEYB GR will generate € with
AltGr+5. (most likely because that's the € position on my US-ASCII
keyboard, but that's ~20 years back in time)

I took this opportunity to fix the € sign in all supported keybords,
at least I hope so.

now they will generate 213 with AltGr+E, whatever the codepage. with a
proper codepage, this will look like €.

download from www.drivesnapshot.de/freedos/mkeyb.zip

Tom






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

Re: [Freedos-user] MKEYB related stuff

[tom ehlert]

>> codepage is a display thing, essentially it's the table how to
>> convert 8-bit bytes into a visable character set, and mostly
>> unrelated to the way the keyboard driver converts scancodes into
>> bytes.

> The Code Page and the Keyboard layout are not unrelated at all -- -- they are 
> HIGHLY related.

nope.

it's not uncommon  for germans to use US-ASCII keyboards (QWERTY).
other use german keyboards (QWERTZ).

in both cases the codepage is 437 (BIOS default) or 858 (with €), but
Y and Z are swapped.

the same is probably true for french keyboards.

what you want is "GR" or "FR", which is not avaliable in a documented
way.


Tom




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

Re: [Freedos-user] MKEYB related stuff

[tom ehlert]

> On 07/10/2021 18:47, tom ehlert wrote:
>> were these 2 layouts dynamically switchable (and actually
>> switched)

> They were actually not switchable, mainly due to their implementation:
> CP852 was provided by "mode con cp" through MS-DOS, while the Mazovia 
> codepage was usually loaded through a custom TSR (maz.exe comes to 
> mind). Hence "switching" required to unload maz.exe and run the 
> appropriate mode con cp prepare/select combo. And that's what I was 
> doing whenever I needed to use a program that was assuming CP852.

> But now, since Mazovia and CP852 are both supported by FreeDOS, they can
> be easily switched without relying on any exotic TSRs.

> The full story is that when the IBM PC came to Poland, it wasn't 
> handling Polish glyphs at all, so Poles had to come up with their own 
> codepage when creating their IBM PC clone (Mazovia 1016). It was first
> burned in custom ROMs, and later - with VGA cards - loaded to the VGA 
> memory through TSRs.
> Then, later, Microsoft/IBM decided to support Polish, and did so by 
> cramming most of east-European glyphs into CP852... Which not only led
> to a poorly usable codepage (garbled Norton Commander semigraphics!), 
> but also introduced chaos in the way Poles were exchanging text. Some 
> started using the Microsoft 852 page, since it was meant to be the "new
> standard", and others kept using Mazovia since it was superior and 
> well-established... Ah, those good times.

so there would be 2 polish keyboard layouts: PLMAZ and PL852.

still no way to communicate this between KEYB and DISPLAY and PRINTER.

maybe just switch to Windows/Linux and UTF-whatever ;)

Tom



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

Re: [Freedos-user] MKEYB related stuff

[tom ehlert]

> Plus, you can have situations where there is not a unique set of
> ASCII/scan code combinations.  E.g., ASCII 13 (Carriage Return) can
> be generated by Enter, Grey Enter (on the NumPad), Ctrl-M, Alt-013,
> and maybe other ways too.  If the user tells me to "type" an ASCII 13, which 
> key(s) do I use?

the user told you to type ASCII 13. why don't you 'type'  0x13 using
INT16, AH=05h? use scancode 0x02 and send complains to me?

in addition, many keyboard handlers were able to produce 'keys' by
holding down ALT and hitting 3 decimal keys to produce a 'ASCII' code.

your attempt to the problem is just wrong.
if a user calls
   SCANCODE -some options   "ÄÖÜà"

the best solution that "ÄÖÜà" survives the the back and forth
translation is to use INT 16, AH= 5

> Exactly.  That's why I need to know what the keyboard layout is,
> including things like dead keys.
as there are no standards about 'keyboard translation tables', you
would have to carry all this information in your SCANCODE tsr.



> There are also some keyboard
> layouts with more than one mode (like various Hebrew, Cyrillic, &
> Greek ones) where there is a "Latin/English Mode" and a "Foreign
> Mode" and pressing the "a" key when it's in Foreign Mode doesn't generate an 
> "a".
I still think that

   SCANCODE some options   'a'

should send 'a' to my program, whatever the codepage is.

> No, there are enough controversial keyboard layouts to make it a
> big problem.  The main keyboard layouts I'm aware of that are VERY
> different than "common" keyboards are Dvorak, Dvorak Left-hand,
> Dvorak Right-hand, Colemak, Bulgaria (BG) 241, and Turkey (TR) 440. 
> They are not commonly used, but there are DOS drivers for them (in
> FD-KEYB) and they are used by some people.  There are also keyboards
> where even the number keys at the top of the keyboard are different,
> not just the letter keys.  Knowledge of the current keyboard layout
> is an important, not a trivial, thing.

good luck with that.
I don't think that is solvable in 8-bit land. and xxDOS is very much
8-bit land.

Tom



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

Re: [Freedos-user] MKEYB related stuff

[tom ehlert]

Hallo Herr Mateusz Viste,

am Donnerstag, 7. Oktober 2021 um 17:00 schrieben Sie:

> On 07/10/2021 15:43, tom ehlert wrote:
>>> DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to
>>> inform KEYB so it can change its mapping.
>> please provide an example where this is necessary AND plausible.

> In Poland, there were a few codepages used during the DOS era. The two
> main ones were CP911 ("Mazovia") and CP852. The character mappings are
> different, for instance "ą" (ALT+a) is byte 0xA5 in CP852, while in 
> Mazovia it is under 0x86. Most polish programs could be configured to 
> output their content in one of the codepages, but some were hard-coded
> to either Mazovia or CP852. In such cases, a mode con cp select was 
> required -- in such case, a non-smart keyb driver would not be aware of
> the change and keep emitting byte codes for the initial codepage it was
> configured for.

thank you very much for explaining this as I (as a german) have no experience
at all with DISPLAY, codepages and friends. in particular not with 2
codepages, different from 437, *at the same time*.

were these 2 layouts dynamically switchable (and actually
switched), or would one computer select one of the 2 codepages at
setup time, and usually remain so for the rest of their lives?

Tom



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

Re: [Freedos-user] MKEYB related stuff

[tom ehlert]

>> how should a KEYB scancode->keycode driver react to copdepage
>> changes, and how are these communictated?

> Well, first of all the keyboard driver should detect the current
> Code Page on installation and not just assume one.
codepage is a display thing, essentially it's the table how to convert
8-bit bytes into a visable character set, and mostly unrelated to the
way the keyboard driver converts scancodes into bytes.


with an US keyboard driver,
pressing the '7' key (scancode 0x08) results in '7'.
pressing the '7' key while holding SHIFT results in '&'.
pressing the '7' key while holding AltGr results in nothing.

with an GR keyboard driver,
pressing the '7' key (scancode 0x08) results in '7'.
pressing the '7' key while holding SHIFT results in '/'.
pressing the '7' key while holding AltGr results in '{'.


>  And, the KEYB
> program should work with multiple code pages when it can.
they all do. they always produce the same byte values öäüÖÄÜ whatever
the codepage.

of course a brasilian KEYB might produce different values for á then a
french KEYB (I don't know), but they still produce the same value
consistently.

> DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to
> inform KEYB so it can change its mapping.
please provide an example where this is necessary AND plausible.

> Unless the tables are in a "public" format, the data contained in
> the tables is irrelevant.

> The reason that other TSR's (at least mine) may need to know what
> the keyboard mapping looks like is because they need to do an
> "ASCII-to-Scancode" lookup.
nope. you intend to do "ASCII-to-Scancode" lookup, then feed these
scancode to the KEYB program, in the hope that this KEYB program
converts it back to the same ASCII character that you started with.

there's a BIOS call for this:
KEYBOARD - STORE KEYSTROKE IN KEYBOARD BUFFER (AT/PS w enh keybd only)

AH = 05h
CH = BIOS scan code
CL = ASCII character

use '2' as scancode. compatible with 99,95% of al existing
applications.

otherwise you have to implement what the KEYB program does in reverse
direction. not only different scancodes with different shift states,
but also dead keys: á is produced by hitting ´, then a; à is produces
by holding SHIFT, hitting `, hitting a, releasing SHIFT.
for the german keyboard at least ;)

or
AH = 05h
CH = 02h
CL = à
int 0x16


> My SCANCODE program, e.g., "types" scancodes automatically (it is
> useful for creating "macros"), but the user can tell SCANCODE what
> to "type" with ASCII codes.  To do this, SCANCODE needs to know what
> scancode(s) to type (what physical key(s) on the keyboard to press)
> to generate the ASCII code the user wants to see.  For example, if
> you tell SCANCODE to type a "Z" it will press the shift-key, press
> the "z", release the "z", then release the shift-key.  But, it needs
> to know where the Z key is on the keyboard to do that, and the Z key
> is in different places (different scancodes) depending on the
> keyboard layout and, in some cases, the code page.

yes that's complicated. how about sending 'Z' to the program?


> Another kind of TSR that needs to know is a TSR that has some sort
> of "hot-key" to enter into the TSR as it is running to make
> configuration changes.  My CLOCK and SERIAL programs do this.  TSR's
> usually (though not always) monitor scan codes for hot-keys rather
> than ASCII codes, but the user usually enters the hot-key as an
> ASCII code.  The current versions of CLOCK and SERIAL simply assume
> the keyboard is a standard US QWERTY layout, but I'm in process of
> changing them to be "keyboard-layout aware").

there are enough 'non-controversial' keys to use for hotkey; just use
B-X and avoid Q.

Tom




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

Re: [Freedos-user] changing keyboard layout after booting from CD-ROM

[tom ehlert]

>>> Another one is that MKEYB doesn't
>>> report itself correctly as a "standard" keyboard driver to other
>>> programs which can cause some compatibility problems.

>> no one complained so far. ever. in 15+ years.

> Well, then consider this your first complaint.  I don't use MKEYB for this 
> and other reasons.

>> how would this report look like?

> Look at RBIL, INT 2F.AD80 and related calls.

> As Aitor alluded to, KEYB interacts with the various other things
> in DOS (COUNTRY, DISPLAY, CHCP, NLSFUNC, ...).  If KEYB doesn't
> report itself through that mechanism the other DOS functions may not
> work correctly.
admittedly, I'm a german user, who had never anything then an US-ASCII
keyboard, never used anything of the DISPLAY, CHCP, NLSFUNC family
*ever* and so I am certainly not experianced on these things.

how should a KEYB scancode->keycode driver react to copdepage changes,
and how are these communictated?

why would any other TSR need insight into KEYB installed/not installed
state or a pointer to private tables?


> But, it's usually only a problem if you try to
> switch between languages or keyboard layouts or code pages on the
> same computer, which very few people do.
even then, I only see
  'changing between keyboard translation and no translation'
 which MKEYB should support.

 > It's also a problem for other programs (including other TSR's) that
> need to know the current keyboard layout for some reason (which some of mine 
> do).
why would they want to know this? just pass around scancodes, and
MKEYB will be happy.

Tom




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

Re: [Freedos-user] changing keyboard layout after booting from CD-ROM

[tom ehlert]

>  Another one is that MKEYB doesn't
> report itself correctly as a "standard" keyboard driver to other
> programs which can cause some compatibility problems.
no one complained so far. ever. in 15+ years.

how would this report look like?

>  MKEYB may work just fine for you, though.
;)

Tom



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

[Freedos-user] Old school: I work in DOS for an entire day

[tom ehlert]

https://arstechnica.com/information-technology/2021/07/dos-boot-ars-spends-a-day-working-in-freedos/

Enjoy!



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

Re: [Freedos-user] Building Plan9's Sam text editor on FreeDOS? (+ Edlin without line numbers?)

[tom ehlert]

> The only light at the end of the tunnel right now is something like
> HX DOS, which allows you to run SIMPLE Win32 apps in DOS. Give it a
> try: https://www.japheth.de/HX.html

DOES IT WORK IN A REASONABLE WAY?



> More realistic solution would be to crowdfund some developer to
> write a DOS port in something like https://github.com/SuperIlu/DOjS
> (but I'm not sure about performance on 486 and lower, running Pentium 1 would 
> be more safe).

have you even the slightest ide how nuch time it takes to write a DOS
port? multiply this by the minimum wage law of your country.


maybe Jim Hall should it port on his video channel.


> Try to run it in FreeDOS again using HX GUI / HX RT.
did this work for you?

Tom



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

Re: [Freedos-user] Creating a FreeDOS compatibility page in the wiki?

[tom ehlert]

> Looking for feedback on creating a "software compatibility" list on
> the FreeDOS wiki.
Easy in ~2002.
either software worked as well in freedos as in msdos, or it was a
bug to be fixed.

first it was Bart and me fixing 16 Bit stuff (fixing 300+ bugs),
later Michael Devore fixed a huge number of bugs for DPMI(32 Bit
stuff), and Japheth clearing (most of) the rest.

in ~2003, IMO most relevant bugs were fixed.

> Sometimes, people say they have problems running some game or other
> software on FreeDOS.
sure as hell. sometimes people have even trouble to drive on the right
side of the street.


> Recent examples include Windows 3.11,
it's not a recent example. Windows 3.11 requires some interfaces (APIs)
that are a) mostly undocumented and b) neither Bart, me, or any follow
up developer cared about to invest valuable lifetime. organize a 7
digit amount of $ and this might change.


> and some CD-based games that use copy protection.
cool. copy protection used more or less by definition
undocumented/sparsely documented functions.

I see no reason to invest time into this. recommend OAKCDROM instead.


> What would be the best way to track these issues, and provide a way
> for people to find a fix or workaround?
track these issues in a single place. not scattered in a couple of
non-searchable mailing lists, SLACK, or where ever...


> I'm thinking of a "software compatibility" page on the wiki. I don't
> think this should be a huge list of "this software works" but a
> shorter list of "this software doesn't run (with default config?) on
> FreeDOS" and some workarounds (if we know them).

just go ahead

Tom



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

Re: [Freedos-user] Creating a FreeDOS compatibility page in the wiki?

[tom ehlert]

> I am not going to install VirtualBox
> I am not going to install Bochs
> I am not going to install QEMU
> I am not going to install VMware
> I am not going to install VirtualPC

> So I am not going to copy paste my unstructured collection of
> compatibility issues into a wiki if nobody can be bothered to
> answer my question whether any of the above STILL have the
> alleged bugs of:

> - being incompatible with VME, INVLPG or PGE in JEMM...
> - being incompatible with UHDD UltraDMA modes

it would be helpful for people with these environments if you could
provide PRECISE instructions how to determine if these
incompatibalities exist or are solved. no 14KB rant, but like

   run EMM386 with option XYZ
   see if program ABC works (and a clear description how Joe Average can
   determine if program ABC works).


> The discussion about dropping games because VirtualBox is
> too broken to emulate a decent VGA was bad enough already.

while I'm absolutely not a fan of distributing multi megabytes of
games/emulators/exoctic compilers in the first place
(in DOS world there was a clear separation
between operating system, and stuff that runs on this operating
system), incompatibility with VirtualBox is NO good reason to change
any policy.

Tom



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

Re: [Freedos-user] Creating a FreeDOS compatibility page in the wiki?

[tom ehlert]

for all of you that are missing a TLDR section of the post below:

there are a lot of problems with many software, games are more
problematic.

for many configurations there are some config.sys options to make
things work.

unfortunately you have to work this out for yourself.

Tom



am Samstag, 19. Juni 2021 um 16:47 schrieben Sie:


> Hi Jim, virtual computer users,

>>> http://wiki.freedos.org/wiki/index.php/Hardware_compatibility

> How about adding advice about specific hardware to that? Some examples:

> JEMM386 and JEMMEX may need options NOPGE, NOVME or NOINVLPG or
> for buggy versions of Qemu, Bochs, VirtualBox, VMware or VirtualPC
> and for 2017 Ryzen CPU: Those have VME, but it is buggy, so JEMM...
> would try to use it. Also, avoid I=TEST unless you know it works.

> You may have to use X2MAX=32767 or EMX options of JEMM... for some
> games or manually override the A20METHOD if necessary. For some PCI
> sound blaster variant drivers, the SB JEMM... option will be needed.

> The A20 method overrides also apply to HIMEM and similar drivers.
> With HIMEMX, use /X2MAX32 to limit XMS 2.0 to 32767k for old games.

> For UHDD (and the older UIDE) you can use /E to disable UDMA and
> use slow BIOS I/O for all disks: Some versions of VirtualBox and
> mainboards older than 1995 may need this. On modern boards, you
> can use /O to overlap disk I/O with XMS access, but try whether
> it works before using it. For some old games, the /R15 or /R63
> options for UHDD may be beeded to keep the first 16 or 64 MB of
> RAM free for the games, if they cannot access higher addresses.
> For old systems with broken DRQ, the /Q option might be useful.

> For UDVD2, very few old LiteON drives report UDMA, but not support
> it properly: Use the /UX option for those. Do not use it by default,
> it drastically reduces speed!

> All sorts of sound hardware have all sorts of special tricks needed
> at boot to get them work as intended. In particular, PCI ones are
> evil and may only fully work on mainboards which support DDMA. Any
> hardware Adlib / OPL3 FM emulation may work nevertheless. See above
> for software emulations: Special JEMM... options may be necessary
> and various games may be incompatible. For playing CD audio, some
> wiring between CD/DVD drive and mainboard/soundcard will be needed
> and special mixer volume control and driver settings will apply.

> Windows 3.x must be run in standard mode, not 386enh mode, but
> in DOSEMU2, 386enh mode and Windows for Workgroups "non-safe" mode
> may work with some effort. Complicated topic, see tutorials etc.

> I guess DPMIONE or similar could help you to run 386enh mode, too?
> And of course you can use Japheth's HX RT and HX GUI to directly
> run older or simpler Windows apps in DOS without any Windows :-)

> Another relevant thing is: ALWAYS load XMS/HMA drivers if you can,
> HIMEM family, XMGR or, if your CPU is 286, at least FDXMS286. All
> is better than nothing and DOS=HIGH and FreeCOM command.com with
> XMS swap make a huge difference for having more of your 640k low
> DOS memory free. If you cannot load such drivers, consider using a
> KSSF disk-swapping version of FreeCOM instead of default XMS-swap.

> In general, avoiding JEMM... or EMM386 can avoid problems, both
> with buggy hardware/BIOS and with buggy or old games, but you
> cannot load things to UMB without that unless you use UMBPCI and
> UMBPCI has limited compatibility itself (test before use!). One
> trick to get more free RAM is to use DEVLOAD to load UDVD2 and
> UHDD with their /H options to let them use HMA instead of UMB.

> I am sure that I have forgotten MANY compatibility tricks here, but
> I would like to hear from all you "virtual computer" users out there
> which of the abovementioned suspected incompatibilities with Bochs,
> QEMU, VirtualBox, Virtual PC, VMware etc. actually still apply to the
> CURRENT versions of those :-)

> Maybe somebody can add a more structured version of the above to the
> compatibility wiki page. I will not, I can only give you this dump
> of ideas from my memory and from various readme files here ;-)

> Thanks for reviewing! Eric

> PS: Interestingly, the PCEM UDVD2 combination find the track count,
> but not track lengths for audio CD, due to some PCEM compatibility
> issue, so only SIMPLE audio CD players will work, not normal ones,
> as the latter think that no non-empty audio tracks would exist.



> ___________
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user



Hallo Herr FreeDOS.,




Mit freundlichen Grüßen / with kind regards
Tom Ehlert
+49-241-79886



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

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[tom ehlert]

Hallo Herr Jerome Shidel,

am Mittwoch, 2. Juni 2021 um 02:39 schrieben Sie:



>> On Jun 1, 2021, at 11:10 AM, Eric Auer  wrote:
>> 
>> 
>> Hi Lukas,
>> […]
>> 
>>> said it is memory issue and solved also by installing FreeDOS on hard drive
>>> in Pentium machine. That's how I did it as well and it works. Even
>>> installing a lot of packages on 486, the fdimples will crash with out of
>>> memory while browsing packages tree and selecting many packages.
>> 
>> That sounds as if FDIMPLES had too little DOS memory free?

> It is related to memory. However, not really tied to how much free
> memory is available on his machine. 

> Like I’ve mentioned many times before… FDIMPLES is just a front end
> UI. Actual installation and removal of packages is done by FDINST (part of 
> the FDNPKG package).

> For the end user, this isn’t important. However to install some
> really big packages, FDINST requires a lot of low memory. This means
> FDIMPLES has to have a very small memory footprint. 

> FDIMPLES looks simple. However, it correlates multiple pieces of
> data. Something like as little as 1 up to about 8 different metadata
> files and a handful of other data points for each entry. 

> All of that is pulled through something that resembles a
> prioritized cache. As it runs out of memory, it discards less
> important data first then ever more important data until sufficient
> memory is available to complete its current task.

> Basically with the extreme memory constraints placed on it.
> Sometimes, it gets stuck needing some low importance data and is
> forced to hold onto or keep recaching the same data.

> Just having FDIMPLES reserve more RAM for itself would fix it. But,
> then insufficient memory would be available to FDINST to install some of the 
> really big packages.

> The current version of FDIMPLES improved this a lot. But, it still
> does happen far to often (like at all). I just need to find the time to 
> completely resolve it.

> With the little RAM it is permitted to consume, I’m often amazed it manages 
> to work at all.

given the fact that FDINST is some sort of glorified UNZIP, you need an amazing
amount of words to describe the process.

Tom



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

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[tom ehlert]

> You see how many subscribers and views Phil has.
it's always kind to not only mention 'Phil', but be more specific like
"go to Youtube.com, search FreeDOS 1.2 Review - Can it replace MS DOS
for retro gaming?"
or even give the link directly. https://www.youtube.com/watch?v=zGmCVeAKR4w

otherwise you are just trolling.

> There are others
> like this on Youtube. Everyone from time to time tries FreeDOS for
> gaming hoping that this time it will be more modern and efficient
> solution for this type of use. Every discussion ends that it does
> not work and it is not worth it. And I think end of our discussion will be 
> similar.

if you would watch the video yourself, you would learn that MANY games
work right out of the box, and most others work after replacing some
files (mostly UDVD2.SYS) with updated versions and skipping EMM386.
I'm not sure what you are so loudly complaining about.

yes, Phil is right to complain that FreeDOS doesn't distribute some
updated components after several years of existence.

but that's an entirely different story.

Tom



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

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[tom ehlert]

> A lot of games I tried with JEMM386/JEMMEX had some really jarring 
> issues. They varied from the game gracefully crashing to outright raping
> my ears or gradually eroding FAT away. FreeDOS' own FAT repair tools 
> couldn't help me. Only nuking everything and re-installing and 
> re-configuring everything. At this point I've included a special GRUB 
> entry that uses a Linux distro coupled with a custom init script to fix
> my FDOS partition. I lost a lot of time and mental wellbeing on these 

did you ever hear about the concept of BACKUP/RESTORE?

Tom






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

Re: [Freedos-user] FreeDOS and screen readers for blind users

[tom ehlert]

> Two follow-ups:
> 1. My installation is based on FreeDOS 1.3 RC3. Is there a stable
> version incorporating ASAP somewhere?
as ASAP seems to have commercial license: no.
https://en.wikipedia.org/wiki/List_of_screen_readers


> 2. I'd love to go native with DOS, preferrably booting from a USB
> flash drive.
good luck with that.

> Of course insodoing I lose my speech synthesizer emulator
> as this is Windows-hosted. This leads to the following sub-problems:

> a) Can FreeDOS boot from a flash drive?
yes. every BIOS for the last 15 years can.
however, good luck if you have to tweak some BIOS options should this
be needed.

in some cases the BIOS does not allow to boot from USB automatically
(to prevent booting from (intentionally?) forgotten USB sticks), and
you have to press some key first, then select the USB disk from a
menu. good luck with that either.

> b) Can it subsequently have write access to that drive?
most likely, yes.

> c) Is there a software speech synth for FreeDOS for contemporary
> on-board sound hardware?
almost definitively no. there is exactly zero support for contemporary
anything in anyDOS (that is not supported by the BIOS itself),


> Thanks in advance for any clues, and all the best,


Tom



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

Re: [Freedos-user] FreeDOS on UEFI and other present and future hardware tricks

[tom ehlert]

Hi Eric,

> And for various reasons, Stas has spent a lot of work to pull
> most of the FreeDOS kernel over into the protected mode space
> in context of dosemu2. That module is now called fdpp. It lacks
> the init-text and the hma-text part runs on the Linux side,
> with dosemu-specific connectors residing on the DOS side.

> This makes it somewhat convoluted to "package" the heavily
> updated fdpp kernel back into a classic "kernel.sys loaded by
> a boot sector" infrastructure again and of course some things
> are now optimized for protected mode. So it can be frustrating
> that many updates for the kernel have ended up somewhat out of
> reach, backporting them would require tedious cherry picking.

now it would be interesting to hear about these 'heavy' updates, that
happened completely in the dark for FreeDOS developers.

what do they do? fix bugs? improve compatibility? where are they
documented?

it would be cool to let the freedos kernel developers decide if these
changes are out of scope, or if cherry picking might be possible and
worth the effort.



Tom



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

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[tom ehlert]

> First, the amount of RAM available varies greatly making it an all or nothing 
> prospect.

> Second, unzip requires DMPI and wants HD swap. Unless the binary is
> somehow modified at boot, it will complain about no C drive swap.
> Also with no swap and limited RAM constraints, it is potential point of 
> failure.

just unzip base.zip, put the executables into a directory (\FDOS?) on the
CD/DVD, point PATH to it, and call it a day. it's hardly more then a
few MB.

absolutely not necessary to unpack on every boot.

Tom




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

Re: [Freedos-user] DOS on (very) small form factor PCs?

[tom ehlert]

> ...the board format does not matter much.
> It's the CPU model/generation that matters.

NOT. AT. ALL.

each Intel/AMD CPU produced the last 20 years is able
to execute the same way that the previous versions did.

(with the exception that there might be CPU sepcific
microcode updates necessary,but this is completely aside
and above this discussion)

it's the (FlashEprom) firmware on the motherboard
that makes it 'BIOS' or 'UEFI' compatible. In 2021
virtually ALL available motherboards support both ways to
provide service to the rest of the world, both BIOS and UEFI.

However some one (Microsoft?) has announced that from now on
'modern' firmware needs no longer to provide 'BIOS' support

**
to make that clear:

there is no 'UEFI' or 'BIOS' firmware.

there is only firmware (a program in some EPROM) which provides
either 'BIOS' style or 'UEFI' style services


to summarize: unless you have special needs, just every mainboard
produced the last 40 years should work with ANYDOS. Don't ask for
sound...



Tom








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