Re: [Freedos-devel] Where to start and continue?

[Carsten Strotmann via Freedos-devel]

Hi,

On 10 Jan 2023, at 10:13, Knedlik wrote:

> Hello all again,
> thanks for all the responses. Definitely useful stuff. I’d just like to 
> respond to the concerns regarding the VM - I’m afraid I don’t have any 
> silicon able to run FreeDOS. My main computer is not only an overkill (Ryzen 
> 5 3600X, SSD, RTX 2060, 32 gigs of RAM), but I don’t think it supports legacy 
> BIOS. And the secondary I’m on right now is a MacBook with an M1 CPU, so even 
> if I had bootcamp, that option wouldn’t be possible.
> -Knedlik


a dedicated PC emulator might be a better option than an VM

 * PCem https://www.pcem-emulator.co.uk/
 * DOSBOX https://dosbox-x.com/
 * PCE http://www.hampa.ch/pce/
 * PCEjs https://github.com/jsdf/pce

Greetings

Carsten


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

Re: [Freedos-devel] Where to start and continue?

[Carsten Strotmann via Freedos-devel]

Hi,

On 9 Jan 2023, at 19:51, Knedlik wrote:

> Any help with places to learn this stuff will be appreciated.

the Internet Archive has many good (old) books on MS-DOS/PC development that 
are still valid today: 


Greetings

Carsten


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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[Carsten Strotmann]

Hi,

On 25 Aug 2022, at 13:50, Bitácora de Javier Gutiérrez Chamorro wrote:

> I do not think it will be that easy. It is probably hitting the 16 unsigned 
> int range, and also accounting that large memory model only allows to 
> allocate blocks of up to 64K (you are looking for huge).

yes, or it would need a different data structure, not a simple array for the 
text.

Like:
Gap buffer: https://en.wikipedia.org/wiki/Gap_buffer
Rope: https://en.wikipedia.org/wiki/Rope_(data_structure)
Piece Table: https://en.wikipedia.org/wiki/Piece_table

More on the topic:
https://www.texteditors.org/cgi-bin/wiki.pl?DesigningTextEditors

I agree, that is major work. But there are many good (and free) text editors 
available for DOS that can edit large text.

"edit.exe" is a simple and limited tool, but good enough for the intended use 
case.

Greetings

Carsten


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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[Carsten Strotmann]

Hi,

On 25 Aug 2022, at 9:41, Paul Dufresne via Freedos-devel wrote:

> While thinking about 64k limit for edit... I come to think about 16 bits and 
> 32 bits programs...
>

the 64kb limit is an artificial limit in the source code of the "edit" tool:

https://gitlab.com/FreeDOS/base/edit-freedos/-/blob/master/SOURCE/EDIT/EDIT.C

/* check file size */
if (sb.st_size > 64000UL)
{
ermsg = DFmalloc(strlen(FileName)+100); /* alloc fixed 0.7a */
strcpy(ermsg, "File too large for this version of Edit:\n");
strcat(ermsg, FileName);
ErrorMessage(ermsg);
free(ermsg);
return;
}

The program "edit.exe" is compiled in the "large" memory model, it *should* be 
able to use the whole available DOS memory, at least more than 64kb.

Maybe it's time to remove that limit from the tool.

Greetings

Carsten





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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[Carsten Strotmann]

Hi,

On 25 Aug 2022, at 11:07, Paul Dufresne via Freedos-devel wrote:

> Would it be possible to have edit.exe for 64k less files... edit32.exe for 
> bigger files... and edit.bat that would check fif the requested file to edit 
> is bigger than 64k and then call edit32 on the file, else edit.exe on the 
> file?

There is no reason why edit.com should not be able to edit large files. 
Addressing 640KB of RAM is possible on any 8086 PC, and with the help of 
EMS/XMS addressing larger memory is possible.

>From my point of view, there is no need to have a 32bit program to edit files 
>> 64kb.

Greetings

Carsten


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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[Carsten Strotmann]

Hello Paul,

On 25 Aug 2022, at 9:41, Paul Dufresne via Freedos-devel wrote:

> While thinking about 64k limit for edit... I come to think about 16 bits and 
> 32 bits programs...
>
> Why there is no two separate versions of FreeDOS, one for 16 bits CPUs (8086) 
> and one for 32 bits CPU (386+)?
>
> It seems there is a lot of programs that cannot run on 8086... and others 
> that could take advantage of 32 bits compilation.
>
> Does it should not suggest to have two separate versions foir this relatively 
> different needs?
>
>

the 64kb limit is not imposed by DOS. It is a decision made by the developer of 
that application.

A 16bit DOS program running on 16bit FreeDOS can access up to 4 GB of RAM if 
available. But that is something the developer must program that way.

BTW, there is a 64bit version of FreeDOS (but it does not run on bare metal 
hardware):
https://github.com/dosemu2/fdpp

Greetings

Carsten


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

Re: [Freedos-devel] Does FreeDOS (or something) sometime automatically break up an hard disk in 2GB sub-disks?

[Carsten Strotmann]

Hi,

On 6 Oct 2021, at 23:12, Steve Nickolas wrote:

> On Wed, 6 Oct 2021, tom ehlert wrote:
>
>>
 users will have FAR more than 60 GB disk size and you can
 have only 24 drive letters from C: to Z:
>>
>>> Up to 32 under some DOS/Windows versions:
>>> https://en.wikipedia.org/wiki/Drive_letter_assignment#Common_assignments
>>
>> while technically true, it just doesn't make ever sense to have setup
>> split *automatically* a hard disk into 24 (or 32) partitions.
>>
>> this auto partitioning option(?) simply should go the way of the dodo.
>>
>> Tom
>
> For what it's worth, while MS-DOS and PC DOS autopartition, DR DOS doesn't, 
> and just runs FDISK.
>
> That is probably the better route?
>

it would be a better route with an expanded FDISK utility that has a less 
hostile interface for beginners and offers an "auto-partitioning" feature. Some 
of the BSD-Unix installers (OpenBSD, NetBSD) could be used as inspiration.

Greetings

Carsten


signature.asc
Description: OpenPGP digital signature
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Problems in your head?

[Carsten Strotmann]

Hi Tom,

On 21 Jun 2021, at 10:07, tom ehlert wrote:

> Hallo Herr Paul Dufresne via Freedos-devel,
>
> am Montag, 21. Juni 2021 um 02:20 schrieben Sie:
>
>> Frankly, this is in part a note to myselft... but could be
>> considered a follow-up to me trying to compile gnuchess.
>
> so you are sending this mail to MANY other people just to remind
> yourself?
>
>
> what's wrong in your head?
>
> next time please send this mail to yourself.
>

please don't be so negative. If you don't like a post, just ignore it or 
include the sender in your "killfile", but don't push you own policy onto other 
people.

The post from Paul was actually very useful. Other people might run into the 
same issues with the same source or with a similar source and might be learning 
from the successes and failures documented.

I find such posts useful and I would like to see them more often.

Greetings

Carsten


signature.asc
Description: OpenPGP digital signature
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Additional notes on Games

[Carsten Strotmann]

Hi Jim,

On 16 Jun 2021, at 21:01, Jim Hall wrote:

> Instead of PakuPaku, what about some other "PacMan"-like game instead?
> For example, there's Double PacMan, at
> https://breadbingames.itch.io/double-pacman
> (source code at https://github.com/moonorongo/doublePalman .. GNU GPL
> in the 'src' directory)

I agree the PakuPaku "cardware" License is problematic.

PakuPaku is interesting not only as a game, but because it uses the 
undocumented 160x100 16 color CGA mode and can run on a stock IBM PC/XT 8086 
4.77 Mhz.

So PakuPaku also is a useful tool to test old hardware, besides being a nice 
game.

The Authors/Projects website is at 

On the projects page the author writes

>> I'm distributing this game as cardware. If you enjoy it please send a 
>> postcard to the provided address. The code for the game is released to the 
>> public domain. Do what you like with it so long as credit is given to the 
>> copyright holder, Jason M. Knight. I have included the full Pascal and 
>> Assembler source code to the game in the distribution. Feel free to play 
>> with it, come up with anything cool from it let me know.  <<

My understanding is that the PakuPaku "binaries" on the page are "cardware", 
but the source is "public domain". The game itself does not seem to mention 
"cardware".

I'm willing to contact Jason M. Knight to clarify the source code license. If 
the license is public domain, the FreeDOS project could create own binaries 
(maybe port to FreePascal) without the cardware license restriction.

Greetings

Carsten



signature.asc
Description: OpenPGP digital signature
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Additional notes on Games

[Carsten Strotmann]

Hi Jim,

On 16 Jun 2021, at 21:01, Jim Hall wrote:

> * Magnetic says in the startup that it is an interpreter for Magnetic
> Scrolls games. but there aren't any Magnetic Scrolls games installed
> with it, so I can't play anything with it. GNU GPL, but the game
> doesn't seem useful without any Magnetic Scrolls games to play. I'm
> wondering if we need this game, or can we find another game to replace
> it?

the data files for Magnetic can be downloaded from 
, but they are not free and 
can't be legally distributed. It would be possible to create a download batch 
script that will download and install the data files for each game to be used 
with the "magnetic" interpreter.

Greetings

Carsten


signature.asc
Description: OpenPGP digital signature
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)

[Carsten Strotmann]

Hi,

On 31 May 2021, at 22:41, Eric Auer wrote:


You say, OK, you can hook a INT 2Fh in your application. But

why the application programmer should hook some interrupts?


The book "DOS Internals" by Geoff Chappell 
(https://www.geoffchappell.com/notes/dos/internals/index.htm) has a good 
discussion on the matter in Section "Logical Drive Mapping", Page 633ff.


INT 2Fh Function 4a00h has never been documented by Microsoft and even 
Microsoft has missed to used that API in "MSD" and "Windows 3x" 
(according to the book it even can "hang" Windows).


That is never has been officially documented by Microsoft might be a 
reason that most programmers don't know about it.





Because by design, the kernel is what knows when you want to
ask the user to change disks, so it is straightforward that
the kernel has to call (a place hookable by) the app if it
wants to give the app a chance to show a message about that.

Just disabling the whole feature because you do not like the
direction of data flow is a somewhat unusual solution, but
again, I suggest that you make a TSR to disable the message.


A TSR hooking INT 2Fh (4a00h) would disable the message, but will create 
the situation where write access that (maybe by accident) is directed to 
drive B: will end up accessing drive A:, causing potential data loss.


It would be better to have a solution where the user could disable the 
logical drive B:, so that access to drive B: will result in a proper 
error code being returned to the application. Most applications can 
handle an error code given back.


Without support from the kernel it might be possible to manipulate the 
DPB (Drive Parameter Block) to remove or invalidate drive B:, or write a 
TSR that hooks INT 13h and terminates all access to B: with an error 
return code. Both solutions are "hacks" and brittle. Support for 
disabling the logical drive B: in the DOS kernel would be more clean, 
IMHO.


Greetings

Carsten




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

Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)

[Carsten Strotmann]

Hello Eric,

On 31 May 2021, at 14:39, Eric Auer wrote:


Hi Mercury, Steve, Carsten and Ladislav:

You are all ignoring the fact that you can simply use the already
existing API to provide your own, graphical floppy change (or DJ
mechanism) dialogue. There is no need to re-invent the wheel!

INT 2F CU - DOS 5+ - FLOPPY-DISK LOGICAL DRIVE CHANGE NOTIFICATION
AX = 4A00h
CX = h
DH = new drive number
DL = current drive number
Return: CX = h to skip "Insert diskette for drive X:" message
Note:   called by MS-DOS 5.0+ IO.SYS just before displaying the 
message

  "Insert diskette for drive X:" on single-floppy systems

Your apps can hook int 2f, function 4a00. If it returns cx=-1 then
DOS will assume that you have already asked the user to switch to
the new disk. DOS will not show a text message about that and will
not wait for keyboard input if you do this.
Eric




this helps for new applications or applications where we have the 
source, but it does not help with all the existing applications 
(possibly closed source).


If I understand correctly, the desired effect would be that access to 
floppy B: without a physical 2nd floppy in the system will return an 
error to the application instead of the DOS kernel intercepting the 
access and prompt for a floppy change.


This might already be possible with the available drivers/config.sys 
options.


Greetings

Carsten


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

Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)

[Carsten Strotmann]

Hi Ladislav,

On 30 May 2021, at 23:44, Ladislav Lacina wrote:

Maybe is a time to consider whether to break the MS-DOS compatibility 
about
handling the one physical diskette drive as two logical drives - A: 
and B:


It maybe had some reason in 1982 but now?


the same reason that was valid in 1982 is still valid today: machines 
with only one floppy drive and no harddisk. I have a couple of these 
machines where I use FreeDOS on (not only old machines, even some 
relatively modern machines where the hard drives have been removed).


The function is important when working in such environments.

However it might be possible to introduce a configuration option in 
config.sys that disables this function if users wish (or even inhibit 
the phantom drive B: by default in case FreeDOS detects at least one 
usable hard-drive partition during boot-up).


Greetings

Carsten


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

Re: [Freedos-devel] DPMIone DPMI 1.0 Server is now open source (GPLv3)

[Carsten Strotmann]

Hi,

On 4 May 2021, at 17:01, Carsten Strotmann wrote:

The license has been changed by the original author from commercial 
license to free software (GPLv3) in April.


correction: the readme was updated to reflect the license, but it seems 
the code was GPLv3 all the time. Sorry for the confusion.


-- CS


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

[Freedos-devel] DPMIone DPMI 1.0 Server is now open source (GPLv3)

[Carsten Strotmann]

Hi,

I just stumbled upon the GitHub repo of DPMIone at 



The license has been changed by the original author from commercial 
license to free software (GPLv3) in April.


This DPMI server might be a nice addition to FreeDOS.

Greetings

Carsten



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

Re: [Freedos-devel] RC4 - list of licenses

[Carsten Strotmann]

Hi Jerome,

thanks for all the good work around FreeDOS.

On 4 May 2021, at 11:19, Jerome Shidel wrote:

> On May 4, 2021, at 3:41 AM, Carsten Strotmann  
wrote:


Hi,

On 3 May 2021, at 22:29, Eric Auer wrote:



RAREAD - doubts about use
RAWRITE - doubts about use
UNRTF - doubts about use
XFDISK - doubts about use
SQLITE - doubts about use


I find the packages above very useful and they should be part of the 
distro, if possible.


When you say “part of the distro,” what are you suggesting?

To clarify...



Yes, sorry, I should have been more clear :)


* Always made instantly available to the Live Environment of the LiveCD?
  - RAREAD
  - RAWRITE
  - XFDISK
  - UNRTF

* Always installed with a FULL install?
  - RAREAD
  - RAWRITE
  - XFDISK
  - UNRTF
  - SQLITE

I also suggest doing the FreeDOS Release Media survey at 
https://fd.lod.bz/survey/ <https://fd.lod.bz/survey/>
Result from that are used to help determine all of the questions I 
mentioned.




Yes, I've done it some time ago, I will revisit it again.

Greetings

Carsten



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

Re: [Freedos-devel] RC4 - list of licenses

[Carsten Strotmann]

Hi,

On 3 May 2021, at 22:29, Eric Auer wrote:



RAREAD - doubts about use
RAWRITE - doubts about use
UNRTF - doubts about use
XFDISK - doubts about use
SQLITE - doubts about use


I find the packages above very useful and they should be part of the 
distro, if possible.


Greetings

Carsten


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