Re: [Freedos-user] piping .BATs (input and output)

[Aitor Santamaría via Freedos-user]

Hello!

I am not quite sure how you intend to manage the stdin input inside the
batch file, but I was wondering if you are looking for something like xargs
(from Unix) and if a port of xargs to DOS would help (extra complexity for
keeping global variables though).

Aitor


El lun, 20 nov 2023, 9:06, Rugxulo via Freedos-user <
freedos-user@lists.sourceforge.net> escribió:

> "%COMSPEC% /c work.bat >file.txt" will succeed. Everyone knows that.
>
> What I'm wondering is if the following (piping into a .BAT) is
> considered acceptable or "standard" for DOS.
>
> "prog1.exe | %COMSPEC% /c work.bat | %COMSPEC% /c fixups.bat >some.txt"
>
> Does that work like I'd expect? (Seems to ... barely.) Is it rare? Is
> it buggy? Is there a better way?
>
> I've explored several other ways in DOS, including other shells (4DOS,
> DJGPP's Bash) or just a simple wrapper .C (system) or .PAS (exec)
> program.
>
> Does anyone have experience or advice with this? (Timo Salmi's BAT FAQ
> didn't quite cover it, from a quick glance.)
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] What DOS programs represent the 1980s and early 90s?

[Aitor Santamaría via Freedos-user]

Hello Jim,

I'm giving my own view that I've lived from this corner of the world.

As for operating systems/environments, it was mostly MS-DOS 3.X, 5.X and
6.22, and of course, Windows 3.1 (before the arrival of Windows95).
I heard of machines having DR-DOS or OS/2, but did never quite catch up.

As for applications, Lotus 1-2-3, WordPerfect and dBase III or IIIplus were
coping with most of the business market and training market.
I had heard (and seen) of Multiplian and Microsoft Works, but I never
really heard or watched a big stack of Microsoft's Word, Excel or Access
until the Windows versions after (and including Office95). Lotus AmiPro
(Windows only) was relatively known, but WordPerfect for Windows (nor, for
example, Lotus Approach) never caught up well.

As for programming Borland products specially, I would say.

And finally for graphics design, I would say Corel Draw!. I was never an
intensive user of publishing software, but around me, the Aldus programs
(like Photostyler and Pagemaker) were better known to me that Adobe's ones,
until Photoshop took over.

I know I have mentioned some that are Windows only. I would be very happy
to see, for example,  FreeDOS+Windows 3.1+Lotus Ami Pro working, but I have
never tried that myself. Back in this mailing lists, IIRC, I posted myself
a MS-Paint image over Windows 3.1 over FreeDOS, but AmiPro is quite a more
complex beast to run.

Aitor




On Mon, 25 Dec 2023 at 05:34, Jim Hall via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> I'm thinking about doing a video that shows how to do real work on DOS. I
> sometimes see comments on YouTube with people asking "could you really do
> *work* with DOS?" And the answer is *of course you can, that happened
> every day.*
>
> So I'm collecting a list of things you'd do in the 80s and 90s with DOS to
> do work. Sure, I'll put a game it two in there, but I'm focusing on getting
> work done.
>
> What programs or types of programs would you like to see?
>
> __
>
> **For myself:*
> *I've done some videos about DOS apps, but nothing like "here's how I did
> everyday work." When I think back to my 1980s and 1990s (especially the
> early 90s) I think of my time at university as a physics undergrad. So
> that's a spreadsheet and a word processor for sure. Probably make a simple
> chart then include that chart in a "lab report" document (or at least leave
> room in the document to print it when I print on a dot matrix printer).
> Probably a dialup terminal to talk to the uni committee lab? File manager.
> And a compiler to write my own tools.*
>
> *The only difference is for the video I'll try to highlight FreeDOS distro
> tools as much as possible, like Doszip for the file manager. *
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] R-Alt does not act like L-Alt

[Aitor Santamaría via Freedos-user]

Hello Eric,

You are right.
In Spanish it happens the same, and I assume in many other keyboard
distributions out there.

So, closed case.
If someone wants R-ALt to act like L-Alt, maybe they can try the KEYB trick
and let us know.

Aitor




On Sat, 28 Oct 2023 at 21:07, Eric Auer via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

>
> Hi Aitor,
>
> I would assume that right alt DELIBERATELY does not act like
> a generic ALT key in EDIT: In German, for example, you need
> that right "Alt Gr" key for some accented characters, so it
> must not act as a function shift key. I remember not being
> able to use some other editor exactly because it treated any
> ALT like ALT, making me unable to type "@" because it wanted
> to treat it like "ALT-Q" or "ALT-@" with a special meaning
> for the ALT status instead of as an ordinary character.
>
> Maybe it would be useful to make this configurable in EDIT,
> but in a minimalist way, for example a checkbox whether R-ALT
> counts as ALT (for hotkeys) or is not to be interfered with.
>
> Regards, Eric
>
>
>
> > Hello,
> >
> > Sounds like it could be a bug in Edit, I'll see about it when I have a
> > little time.
> >
> > Now for the original question: is it possible to make R-Alt work like
> L-Alt?
> > It should be possible to do that with FD-KEYB.The idea is to intercept
> > Right-Alt and then emit Left-Alt, and get back to the BIOS driver. This
> > trick is unlikely lo work in a pre-AT-class machines, but in this older
> > machines, you can try and run FD-KEYB with the /9 and see if it works.
> >
> > The trick is like this: R-Alt is an E0-prefixed L-Alt, so you should
> define
> > a new plane for the E0:
> > [PLANES]
> > ...
> > ...
> > E0
> >
> > Then, make a new mappings sections that would just catch the R-Alt and
> emit
> > a L-Alt (the scancode for Alt is 38h = 56
> >
> > [KEYS:ralt]
> > 5656/#0
> >
> > Finally, add this new mapping to your Submappings section, at the end, so
> > that it works as a fallback for the other cases (change the codepage for
> > whatever you desire):
> >
> > [Submappings]
> > ...
> > ...
> > 437   ralt
> >
> > If someone wants to give it a try and works, let me know, should be
> > interesting stuff.
> > You can apply the same trick to make "extended" keys work as
> non-extended.
> >
> > Aitor
>
>
>
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] R-Alt does not act like L-Alt

[Aitor Santamaría via Freedos-user]

Hello,

Sounds like it could be a bug in Edit, I'll see about it when I have a
little time.

Now for the original question: is it possible to make R-Alt work like L-Alt?
It should be possible to do that with FD-KEYB.The idea is to intercept
Right-Alt and then emit Left-Alt, and get back to the BIOS driver. This
trick is unlikely lo work in a pre-AT-class machines, but in this older
machines, you can try and run FD-KEYB with the /9 and see if it works.

The trick is like this: R-Alt is an E0-prefixed L-Alt, so you should define
a new plane for the E0:
[PLANES]
...
...
E0

Then, make a new mappings sections that would just catch the R-Alt and emit
a L-Alt (the scancode for Alt is 38h = 56

[KEYS:ralt]
5656/#0

Finally, add this new mapping to your Submappings section, at the end, so
that it works as a fallback for the other cases (change the codepage for
whatever you desire):

[Submappings]
...
...
437   ralt

If someone wants to give it a try and works, let me know, should be
interesting stuff.
You can apply the same trick to make "extended" keys work as non-extended.

Aitor


On Tue, 8 Mar 2016 at 20:08, John Hupp  wrote:

> The default FreeDOS 1.1 installation does not load KEYB for a US
> keyboard (nor do I have it loaded). CHCP reports Code Page 858, as
> expected.  And as I reported in my original post on this topic:
>
> - Even in Edit, R-Alt acts like L-Alt with no document open.
> - In SetEdit, R-Alt acts like L-Alt.
> - In FreeDOS Help, R-Alt acts like L-Alt.
> - In DOOM, R-Alt acts like L-Alt.
>
> This led me to think that underlying mechanisms were all in good order
> and not responsible for the (undesirable) behavior in EDIT. So I do
> indeed now think of it as an EDIT problem, and I have adopted SETEDIT as
> a workaround or better alternative on most hardware.
>
> @ Bret: Perhaps you have the skills to offer a fix for EDIT, or can
> convince the current developers to do so!
>
> On 3/8/2016 1:46 PM, Bret Johnson wrote:
> > It is known that the R-Alt (AltGr) works differently than L-Alt with
> some keyboard layouts, but when it is a US keyboard layout (and some other
> layouts as well) that is not the case.  This is a bug and it should be
> fixed.
> >
> > There are DOS functions that EDIT can call to tell what kind of keyboard
> layout is currently implemented and what the current Code Page is (the two
> things are correlated).  However, not all keyboard drivers implement those
> functions properly, so EDIT can end up thinking you're using a US keyboard
> layout when you really aren't.  I know MS-KEYB properly supports these
> functions, but am not sure about FD-KEYB or the other "MS-KEYB clones".
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] KEY language specification for custom keyboard layout?

[Aitor Santamaría via Freedos-user]

Hello there!

The documentation for the KEY language is included within the KC/KLIB
binary distribution:

DOC\KC\KEY.TXT

For some reason, I am no longer able to find the distribution of KC/KLIB
within Ibiblio or GitLab
(maybe Jerome can help?)

But fortunately, there is an online copy at:

http://ftp.lyx.org/pub/freedos/files/dos/keyb/2.0/

the file being KC200X.ZIP

If you want to modify an existing KEY file, you need the package above for
the compiler, and the sources for the KEY files, that they exist in ibiblio:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kblayout/kpdos-3.1/


Thanks and sorry for the delay,
Aitor



On Mon, 29 Feb 2016 at 22:42, John Hupp  wrote:

> Thanks for the confirmation.  I already looked at the DOC folders for
> the KEYB and KC packages and found no help on this question there, so
> I'll hope that Aitor checks in with an answer.
>
> On 2/29/2016 4:31 PM, Henrique Peron wrote:
> > Hi John,
> >
> > yes, the one and only route is to edit the US.KEY file, compile it and
> > run it through KEYB. Correct.
> >
> > You'll have to check the documentation and look for Aitor Santamaría.
> > He's the one to help you with the syntax of a KEY file.
> >
> > Henrique
> >
> >
> > Em 29/02/2016 13:12, John Hupp escreveu:
> >> I'm returning to my quest to customize my US keyboard.
> >>
> >> It looks like the best route for me will be to use the KEYB driver, and
> >> edit the US.KEY file from the KC package, then compile that into a .KL
> >> file to be used by KEYB.
> >>
> >> I understand that the .KEY files conform to the KEY language
> >> specification, but despite some scouring, I have found no documentation
> >> for the format of the .KEY files or the syntax of the KEY language.
> >>
> >> Does anyone have more information?
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] languages

[Aitor Santamaría via Freedos-user]

Ok, thanks for the testing.

Aitor


On Wed, 4 Oct 2023 at 23:36, Joao Silva via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> Hello.
>
> I used KEYB PO,850,KEYBOARD.SYS and worked like a charm.
>
> Thank you.
>
> On Wed, Oct 4, 2023 at 8:43 PM Aitor Santamaría via Freedos-user <
> freedos-user@lists.sourceforge.net> wrote:
>
>> Hi,
>>
>> To do this, you need KEYB itself:
>>
>> ibiblio.org FreeDOS 1.2 Updates Package -- keyb (FreeDOS Base)
>> <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/keyb.html>
>>
>> and KEYBOARD.SYS and the alikes:
>>
>> ibiblio.org FreeDOS 1.2 Updates Package -- KEYB layouts (FreeDOS Base)
>> <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/keyb_lay.html>
>>
>> To find out which and the commandline, this page may help:
>>
>> KPDOS v3.0 - Keyboard Layout Pack for DOS codepages (bootablecd.de)
>> <https://www.bootablecd.de/fdhelp-internet/en/hhstndrd/other/kpdos.htm>
>>
>> if you want to use KEYB for PO and KEYBOARD.SYS
>>
>> KEYB PO,850,KEYBOARD.SYS
>>
>> should do it.
>>
>> Aitor
>>
>>
>>
>>
>> On Tue, 3 Oct 2023 at 23:19, Joao Silva via Freedos-user <
>> freedos-user@lists.sourceforge.net> wrote:
>>
>>> Hello.
>>> I don't have FD-KEYB installed and i can't find fdimples.
>>> Where can i install it?
>>>
>>> On Tue, Oct 3, 2023 at 7:34 PM Aitor Santamaría via Freedos-user <
>>> freedos-user@lists.sourceforge.net> wrote:
>>>
>>>> Hello Joao,
>>>>
>>>> I think in the thread the bug was mentioned to happen in mKEYB, could
>>>> you please try FD-KEYB to see if the bug is there and needs to be corrected
>>>> too?
>>>>
>>>> Thanks,
>>>> Aitor
>>>>
>>>>
>>>> On Mon, 2 Oct 2023 at 07:26, Joao Silva via Freedos-user <
>>>> freedos-user@lists.sourceforge.net> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> On Sun, Oct 1, 2023 at 10:35 PM Jim Hall via Freedos-user <
>>>>> freedos-user@lists.sourceforge.net> wrote:
>>>>>
>>>>>> Joao wrote:
>>>>>> > > 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.
>>>>>> >
>>>>>>
>>>>>>
>>>>>> Tom wrote:
>>>>>> [..]
>>>>>> > >  "i can't write the * with shift and *+" key"
>>>>>> > c) about the worst bug complaint ever. you don't deserve a better
>>>>>> keyboard driver ;(
>>>>>>
>>>>>>
>>>>>> It's not a bad bug complaint. According to Wikipedia (see link) the
>>>>>> asterisk (*) is on the plus (+) key in the Shifted position. It's next
>>>>>> to the "P" key. So "Shift and +" should produce "*" on a
>>>>>> Portuguese/Portugal keyboard.
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/List_of_QWERTY_keyboard_language_variants#Portugal
>>>>>>
>>>>>>
>>>>>> *Also, telling someone "you don't deserve a better keyboard driver" is
>>>>>> not cool. :-( We're all in this together to create a welcoming
>>>>>> environment. Let's treat everyone with respect.
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> Freedos-user mailing list
>>>>>> Freedos-user@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>>>>>
>>>>> ___
>>>>> Freedos-user mailing list
>>>>> Freedos-user@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>>>>
>>>> ___
>>>> Freedos-user mailing list
>>>> Freedos-user@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>>>
>>> ___
>>> Freedos-user mailing list
>>> Freedos-user@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>>
>> ___
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] languages

[Aitor Santamaría via Freedos-user]

Hi,

To do this, you need KEYB itself:

ibiblio.org FreeDOS 1.2 Updates Package -- keyb (FreeDOS Base)
<https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/keyb.html>

and KEYBOARD.SYS and the alikes:

ibiblio.org FreeDOS 1.2 Updates Package -- KEYB layouts (FreeDOS Base)
<https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/keyb_lay.html>

To find out which and the commandline, this page may help:

KPDOS v3.0 - Keyboard Layout Pack for DOS codepages (bootablecd.de)
<https://www.bootablecd.de/fdhelp-internet/en/hhstndrd/other/kpdos.htm>

if you want to use KEYB for PO and KEYBOARD.SYS

KEYB PO,850,KEYBOARD.SYS

should do it.

Aitor




On Tue, 3 Oct 2023 at 23:19, Joao Silva via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> Hello.
> I don't have FD-KEYB installed and i can't find fdimples.
> Where can i install it?
>
> On Tue, Oct 3, 2023 at 7:34 PM Aitor Santamaría via Freedos-user <
> freedos-user@lists.sourceforge.net> wrote:
>
>> Hello Joao,
>>
>> I think in the thread the bug was mentioned to happen in mKEYB, could you
>> please try FD-KEYB to see if the bug is there and needs to be corrected too?
>>
>> Thanks,
>> Aitor
>>
>>
>> On Mon, 2 Oct 2023 at 07:26, Joao Silva via Freedos-user <
>> freedos-user@lists.sourceforge.net> wrote:
>>
>>> 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.
>>>
>>>
>>> On Sun, Oct 1, 2023 at 10:35 PM Jim Hall via Freedos-user <
>>> freedos-user@lists.sourceforge.net> wrote:
>>>
>>>> Joao wrote:
>>>> > > 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.
>>>> >
>>>>
>>>>
>>>> Tom wrote:
>>>> [..]
>>>> > >  "i can't write the * with shift and *+" key"
>>>> > c) about the worst bug complaint ever. you don't deserve a better
>>>> keyboard driver ;(
>>>>
>>>>
>>>> It's not a bad bug complaint. According to Wikipedia (see link) the
>>>> asterisk (*) is on the plus (+) key in the Shifted position. It's next
>>>> to the "P" key. So "Shift and +" should produce "*" on a
>>>> Portuguese/Portugal keyboard.
>>>>
>>>> https://en.wikipedia.org/wiki/List_of_QWERTY_keyboard_language_variants#Portugal
>>>>
>>>>
>>>> *Also, telling someone "you don't deserve a better keyboard driver" is
>>>> not cool. :-( We're all in this together to create a welcoming
>>>> environment. Let's treat everyone with respect.
>>>>
>>>>
>>>> ___
>>>> Freedos-user mailing list
>>>> Freedos-user@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>>>
>>> ___
>>> Freedos-user mailing list
>>> Freedos-user@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>>
>> ___
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] languages

[Aitor Santamaría via Freedos-user]

Hello Joao,

I think in the thread the bug was mentioned to happen in mKEYB, could you
please try FD-KEYB to see if the bug is there and needs to be corrected too?

Thanks,
Aitor


On Mon, 2 Oct 2023 at 07:26, Joao Silva via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> 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.
>
>
> On Sun, Oct 1, 2023 at 10:35 PM Jim Hall via Freedos-user <
> freedos-user@lists.sourceforge.net> wrote:
>
>> Joao wrote:
>> > > 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.
>> >
>>
>>
>> Tom wrote:
>> [..]
>> > >  "i can't write the * with shift and *+" key"
>> > c) about the worst bug complaint ever. you don't deserve a better
>> keyboard driver ;(
>>
>>
>> It's not a bad bug complaint. According to Wikipedia (see link) the
>> asterisk (*) is on the plus (+) key in the Shifted position. It's next
>> to the "P" key. So "Shift and +" should produce "*" on a
>> Portuguese/Portugal keyboard.
>>
>> https://en.wikipedia.org/wiki/List_of_QWERTY_keyboard_language_variants#Portugal
>>
>>
>> *Also, telling someone "you don't deserve a better keyboard driver" is
>> not cool. :-( We're all in this together to create a welcoming
>> environment. Let's treat everyone with respect.
>>
>>
>> ___
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] languages

[Aitor Santamaría via Freedos-user]

Hi,

The question is not very clear to me, but the installation of FreeDOS gives
you choice for lots and lots of keyboard layouts (Keyboard) and codepages
(screen), as well as many National Language Support for kernel.
However, translation of messages can be a bit uneven, depending on the
language.

I suggest you check a FreeDOS installation and see by yourself what you can
find.

Aitor


On Mon, 25 Sept 2023 at 03:07, Rahim Fakir via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> Is it possible to put all languages to freedos
> Languages KEyboard's and so on???
> Rahim 00351 933 5959 74 is bugged sorry
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] languages

[Aitor Santamaría via Freedos-user]

Hello,

Check KEYB an dKeyboard layouts in FreeDOS HELP:

FreeDOS command: keyb (bootablecd.de)

KPDOS v3.0 - Keyboard Layout Pack for DOS codepages (bootablecd.de)


There you may find all layouts of KEYB and available codepages (to be used
with DISPLAY).

KEYB PO,,KEYBOARD.SYS

should work for you, or

KEYB PX,,KEYBRD4.SYS

for international Portuguese.

Aitor







On Fri, 18 Aug 2023 at 20:57, Rahim Fakir via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> How can freeedos, have portugueses keyboard?
> Is it possible to choose the keyboard layout?
> Rahim 00351 933 5959 74
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] How do I change screen resolution?

[Aitor Santamaría via Freedos-user]

Hello,

I would use MODE CON. After all, you want to reconfigure the console, and
that is what MODE CON is for.

Aitor


On Sun, 6 Aug 2023 at 02:10, zerofive--- via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> This question may been asked a million times but I just can't figure it
> out, and googling it gives no results (except telling me that I need to use
> `mode` and some parameters but this just wouldn't give me what I am trying
> to achieve)
> But I found out that `NANSI.SYS` contains a paramter which (I think)
> allows me to set at least 640x480 resolution. I also included it
> (nansi.sys) in FDCONFIG.SYS with parameters `/t18` but it doesnt seem to
> work. Any idea on what could be the issue or I need to do it the other way?
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
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

[Aitor Santamaría via Freedos-user]

Thanks!

Now it works,
Aitor


On Sun, 6 Aug 2023 at 00:12, tom ehlert via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> 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
>
___
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

[Aitor Santamaría via Freedos-user]

Hello!

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

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
> >
> --
> > ___
> > Freedos-user mailing list
> > Freedos-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-user
> >
>
>
>
> --
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.3-RC3 News!

[Aitor Santamaría]

Hello,


On Wed, 7 Jun 2023 at 11:27,  wrote:

> On Mon, 25 May 2020 at 13:26, Jerome Shidel  wrote:
>
>>
>> Why keyb need a 286, it’s a keyboard mapper?
>>
>
> It does not: KEYB /9 should work on 8088 class machines.
>
>
> Wow, this is an old thread (over 3 years)!
>
Well I am a little behind on mail  ;)


> KEYB requiring a 286 or better is based solely on:
>
> $ grep 286 *
> KEYBMSG.DE:STR2_7 = 'KEYB braucht (immer noch) einen AT/286 oder besser';
> KEYBMSG.NLS:STR2_7 = 'Keyb (still) requires an AT/286 or better';
>
> Being an English language and keyboard user, I neither use nor possess
> knowledge on using various NLS support programs like KEYB. So if there is
> support for hardware older than a 286 or options that provide
> compatibility, I would not know they exist.
>
> Watching it, I would say it requires a test, but my answer was based on
two facts:
(1) The G- compiler directive
(2) The fact that originally, it was based on int15h (as mkeyb), but I
wrote the /9 code, to precisely emulate the call of int9h => int 15h.

Sadly, my XT 8088 ceased to work time ago :(

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

Re: [Freedos-user] FreeDOS 1.3-RC3 News!

[Aitor Santamaría]

Hello Jerome,

On Mon, 25 May 2020 at 13:26, Jerome Shidel  wrote:

>
> Why keyb need a 286, it’s a keyboard mapper?
>

It does not: KEYB /9 should work on 8088 class machines.

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

Re: [Freedos-user] How to make the R-Alt key act like L-Alt?

[Aitor Santamaría]

Hello John,

Sorry for being late.

This can be tricky, but feasible with FD-KEYB without recompiling. You can
start from some US layout and try this example, for Alt+X

First, you need to find out the key and scancode that Alt+X produces (that
EDIT receives). I found this page, but there are utilities that may help
you out with this (like KEYCODE).

Keyboard scan codes (freepascal.org)


According to this, Alt+X returns scancode 2Dh  (45)

Define a plane for Left-Alt:

[Planes]
RALT

To emit simply a scancode with 0, you can do the / trick:

[KEYS:k1]
 45C  x  X   0/45

This should work.

Aitor


On Thu, 16 Jul 2015 at 02:48, John Hupp  wrote:

> I'm just using the BIOS keyboard driver (not running KEYB) with a US
> layout keyboard.
>
> What I'm trying to do: In Edit, for instance, R-Alt + F does not open
> the File menu, and R-Alt + X does not exit the program.  I want it to do
> those things just as L-Alt + F and L-Alt + X do, because those L-Alt key
> combinations are awkward for a touch typist.
>
> On 7/15/2015 8:35 PM, Rugxulo wrote:
> > Hi,
> >
> > I'm not 100% sure of what you're trying to do or why.
> >
> > On Wed, Jul 15, 2015 at 6:48 PM, John Hupp 
> wrote:
> >> For a US layout keyboard and the default BIOS keyboard driver: I brought
> >> this issue up a long time ago and learned that by design R-Alt is a dead
> >> key and does not duplicate the functionality of L-Alt.
> >>
> >> Today I have been studying xkeyb and keyb, trying to find a way to get
> >> what I wanted, but I have come up dry so far.
> > AFAIK, xkeyb is totally deprecated in lieu of KEYB. You could instead
> > use something minimal like mKEYB, but that's not obviously a full
> > replacement.
> >
> >> With keyb, documentation notes that one might edit a KEY file and use KC
> >> with that to compile a custom keyboard layout (KL) file to load, and I
> >> am now trying to plow through the KC doc files, but it's pretty dense
> >> reading.
> >>
> >> Can anyone detail or at least outline a solution?
> > So you have KEYB loaded? (dumb question) Do you need it?? Just unload
> > it, and don't worry about it. Or do you actually need it here for
> > foreign language input? What language(s)?
> >
> > IIRC, you can temporarily disable KEYB via Ctrl-Alt-F1 (and re-enable
> > via Ctrl-Alt-F2). Does that help?
> >
> >
> --
> > Don't Limit Your Business. Reach for the Cloud.
> > GigeNET's Cloud Solutions provide you with the tools and support that
> > you need to offload your IT needs and focus on growing your business.
> > Configured For All Businesses. Start Your Cloud Today.
> > https://www.gigenetcloud.com/
> > ___
> > Freedos-user mailing list
> > Freedos-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
>
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.3-RC3 floppy ideas

[Aitor Santamaría]

Hi,

On Sun, 5 Jul 2020 at 18:46, Eric Auer  wrote:

> > Probably just pull COUNTRY.SYS in favor of MKEYB.
>
> Make sure to check whether MKEYB works on 8086: It might
> require AT level BIOS functionality.
>

If that ever becomes a problem, FD-KEYB implements the /9 switch to use in
non-AT class machines.

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

Re: [Freedos-user] FreeDOS/V

[Aitor Santamaría]

Hi,

On Thu, 4 May 2023 at 20:38, Ralf Quint  wrote:

> > * Collating/lowercase/uppercase tables, which in turn implies that
> > DBCS are handled where strings are handled, and my worry is about
> > filenames: how are filenames stored? how does it relate to 8.3
> > limitation, does it become 4.1 or does it require LFN...?
> For one, as DOS/V would specifically apply to Japanese (but the same
> would apply at least to Hangul (Korean) and Chinese), none of the script
> systems being used (Katagana, Hiragana, and certainly not Kanji (Chinese
> "characters")) has the concept of upper case/lower case...
>
Yeah, I know :) I just mentioned for completion, and specially for the
collating table.


> Ok, here is were that soft brown matter hits the fast rotating household
> appliance. I am pretty sure that in order to create a DBCS version of
> MS/PC-DOS, they did not use one and the same code base. Some basic DOS
> function would have to be completely replaced with DBCS aware versions,
> I don't think you can simply maintain dual-capable versions without
> significantly increased memory requirements.
>
Sure thing. Most worrying to me is to deal with DBCS strings where kernel
deals with strings, that is specially on filenames.


> And most importantly, I don't think that we at FreeDOS have simply the
> capacity to do any such adaptation. It would require AT LEAST one person
> that is fluent in English and Japanese, as well as being sufficiently
> proficient in programming.  I don't think there is even remotely anyone
> that could possibly fill that role within the current participants, nor
> even lurkers, or they would be more active (and possibly proposing
> required changes).
>
Agreed.


> This would not only apply to adaptations to the before mentioned East
> Asian languages and scripting systems, but also to things like
> right-to-left systems like Arabic and Hebrew
> (Urdu/Farsi/Pashto/Punjabi/Sindhi/etc)
>
Yeah, that's another adventure that would involve heavier changes in the
console at least.

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

Re: [Freedos-user] FreeDOS/V

[Aitor Santamaría]

Hello!

Although I am some years late, my thoughts on this thread. By the way, a
very interesting thread on localisation for a hard case (the need for DBCS).

These thoughts are provided from the simple logic, not knowing about DOS/V.
In my understanding, supporting Japanese would *at least* require the
following functionalities, where the clue is given by NLSFUNC/COUNTRY:
* Country settings (for date, currency, etc.), that should be easy.
* Collating/lowercase/uppercase tables, which in turn implies that DBCS are
handled where strings are handled, and my worry is about filenames: how are
filenames stored? how does it relate to 8.3 limitation, does it become 4.1
or does it require LFN...?
* All character devices that currently support IOCTL, should support this
DBCS. As we have no PRINTER.SYS for PRN, we just need to focus on CON:
- DISPLAY.SYS does not support DBCS, but I suppose that NNANSI that is
being discussed here will do the work. However:
- It would require KEYB to work with DBCS: this could work well:
   + if no codepage change is to be issued, DBCS can be outed as
"strings" by keyb (with an appropriate KL file)
   + if codepage changes is to be issued (because NNANSI implements
it), it should call  KEYB
* Finally, non-console UI utilities should be made to work with DBCS: this
includes EDIT, INSTALL, ...

All that I can come up with for adding NLS support to DOS (probably there
are more that I am neglecting).

Aitor



On Wed, 8 Jul 2015 at 07:47, sparky4  wrote:

> ah! i will fix that asap
>
> i just changed the configuration and compiled it
>
> thats all
>
> FreeDOS/V is to DOS/V
> like what FreeDOS is to DOS
>
>
>
> --
> View this message in context:
> http://freedos.10956.n7.nabble.com/FreeDOS-V-tp19922p23010.html
> Sent from the FreeDOS - User mailing list archive at Nabble.com.
>
>
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] FD-DISPLAY managed at GitLab

[Aitor Santamaría]

Hello,

As I did with FD-KEYB, I am going to use GitLab solely to track the issues
and enhancement requests (and disregard SourceForge, in order to have only
one source of tickets).

So far I don't have any requested/identified any previous bug or
enhancement requests (except maybe #2, mentioned by Eric Auer long time
ago), so I have created the tickets that I had as possible enhancements
here:

Issues · FreeDOS Archive / Base / display · GitLab


Of course, the list is open to anyone that wants to file any bug or
enhancement request. Please note that I don't have tools to create or
repair CPI/CPX files. Enhancement requests and bugs on these, should be
addressed to these, and not DISPLAY itself.

As with FD-KEYB, in the unlikely event that the lack of these features may
be causing trouble to someone, I may give a try to implement them.
Otherwise, the next milestone for FD-DISPLAY would be to be turned into a
device driver, implementing the true IOCTL calls to the CON driver.

The reason is not only having an implementation more similar to MS-DOS, but
also that it should ease NLSFUNC implementation, which should just loop on
character devices issuing IOCTL calls.

Aitor
___
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?

[Aitor Santamaría]

Hi,

I am a bit late but...

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.
>

It has had many names (DOS386.EXE, WIN386.EXE), but we usually know it as
VMM32.VXD.
Hardware resource sharing is handled in individually loadable modules
called VxD's, that simulate that every DOS machine has the entire
(DOS/BIOS) resources for itself.

No idea - maybe it had been aleady created, just I didn't stumble upon it
> yet?
>
You have (Windows 9X is a privileged GUI that runs in VM0).

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

Re: [Freedos-user] Concept behind RUFUS

[Aitor Santamaría]

Thanks, Liam.

I was looking for the complicated one. :)

Aitor



On Sun, 19 Mar 2023 at 17:22, Liam Proven  wrote:

> On Sat, 18 Mar 2023 at 18:12, Aitor Santamaría  wrote:
> >
> > To those that have used/experience with RUFUS: what is the concept
> behind it?
>
> Um. I am not sure I understand the question. Either it is a very very
> simple question, or a very complicated one.
>
> Simple answer:
>
> Rufus is a Windows tool for making bootable USB keys from ISO images.
>
> Complicated answer:
>
> An "ISO" is a file containing an image of an optical disk (typically a
> CD or a DVD). They are so named because the standard cross platform
> on-disk format for optical media is ISO standard 9660, or ISO9660 for
> short. DOS and DOS-based OSes couldn't support a 7-character file
> extension when the format was ratified.
>
> To make a bootable USB, you need to write a bootloader onto a USB key
> followed by the payload of the OS to be booted. Linux and other non-MS
> OSes usually include this bootloader in the disk image, so you can
> just bit-copy the ISO file to the raw  USB device and it will boot.
>
> (This is partly because they use non-FAT-like filesystems so they put
> a disk image of their native filesystem in the disk image, and a
> bootloader).
>
> Windows ISOs won't, or not always, so you need a tool to install that
> bootloader and then unpack the OS files into an ISO9660 like FS with
> long filename extensions. Because the ISO9660 format is close enough
> to a Windows format, the boot disk doesn't need the fancy virtual
> filesystem stuff, so paradoxically the disk writing tools need to be
> smarter because they need to do _more_ work.
>
> Rufus is a free tool to do this. It is good and reliably makes
> bootable USB keys from Windows ISOs, which Linux tools can't always do
> in my quite extensive experience. However, you need a running Windows
> system _first_ so it poses a chicken-and-egg problem. To install
> Windows you need Windows to make the boot media to load Windows.
> Secondly, Rufus is very _very_ slow. It takes an hour or so. Linux
> takes 5min to write a typical size of disk image.
>
> I regard it as obsolete since I discovered Ventoy. Ventoy does the
> bootup logic internally, so just format a key with Ventoy and copy ISO
> files onto it and it generates a boot menu on the fly and boots DOS or
> Linux or Windows or whatever for you.
>
> Ventoy is great and a huge time saver and it just works, so I don't
> usually use Rufus any more.
>
> --
> Liam Proven ~ Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
> Twitter/LinkedIn: lproven ~ Skype: liamproven
> IoM: (+44) 7624 277612: UK: (+44) 7939-087884
> Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Concept behind RUFUS

[Aitor Santamaría]

Thanks for the explanation, Jeremy.

Perhaps I was looking for a more technical discussion than the average
user, but your mail was exactly what I was looking for.

Aitor


On Sun, 19 Mar 2023 at 00:48, Kenneth Davis  wrote:

> On Sat, Mar 18, 2023, 2:11 PM Aitor Santamaría  wrote:
>
>> Hello,
>>
>> To those that have used/experience with RUFUS: what is the concept behind
>> it?
>> I don't get a clear picture of how this software operates, either reading
>> the site or the wikipedia:
>>
>> It makes "bootable USB" and supports "a variety of ISO", so
>> (a) does it make truly bootable drives, like "SYS D:", where the drive
>> gets a OS file (rewritable) distribution, after transferring the files to
>> the drive (mimicking a INSTALL)?
>>
>
> kinda, yes
>
> (b) copies the ISO into the drive, and somehow mounts the ISO file and
>> boots from there, thereby creating a read-only in memory drive?
>>
>
> no, during creation it reads the files from image and copies them to the
> writable FAT or NTFS formatted disk.  Similar to if you formatted and SYS
> drive, then mount CD image, copy files to disk.  Unless it is in dd mode,
> then it's more of a disk image sector by sector copy to the USB drive -
> this allows filesystems on the drive that Windows does not read or write to
> but requires the image already be setup to be bootable from a USB disk.
>
> (c) ...
>>
>> Thanks in advance,
>> Aitor
>>
>> __
>>
>
> Rufus can be used as a dd or rawrite tool for Windows to USB drives. It
> can also convert isolinux based CD images to boot from USB while keeping
> their options intact. There are some special handling for creating Windows
> install media. And to bring it back to FreeDOS, it includes latest FreeDOS
> kernel and command.com from FreeDOS distribution enabling creating DOS
> bootable USB disks easily. I use it and will copy over latest kernel build
> to boot on real hardware.
>
> Basically you start it, select either FreeDOS or an ISO image, the USB
> drive you want to make bootable,  it clears/creates the partition table,
> formats the drive,  writes boot sector, copies all the files over, replaces
> isolinux with syslinux and voila bootable disk.  Or it works like
> rawriye/dd and copies image file directly to disk but then the image must
> already include boot sector to work.  There are some safety checks so you
> don't overwrite non-removable drives and lots of other details I am
> glossing over.  The author is very approachable and patient with users and
> does an excellent job developing it (its open source so easy to follow its
> development).
>
> Jeremy
>
>> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Concept behind RUFUS

[Aitor Santamaría]

Hello,

To those that have used/experience with RUFUS: what is the concept behind
it?
I don't get a clear picture of how this software operates, either reading
the site or the wikipedia:

It makes "bootable USB" and supports "a variety of ISO", so
(a) does it make truly bootable drives, like "SYS D:", where the drive gets
a OS file (rewritable) distribution, after transferring the files to the
drive (mimicking a INSTALL)?
(b) copies the ISO into the drive, and somehow mounts the ISO file and
boots from there, thereby creating a read-only in memory drive?
(c) ...

Thanks in advance,
Aitor
___
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?

[Aitor Santamaría]

Hello Jim,

Is this list of topics available somewhere on the web? The list here looks
far shorter and does NOT include FreeDOS:

The A to Z list of writing topics for Opensource.com | Opensource.com


Aitor



On Sun, 29 Jan 2023 at 19:40, Jim Hall  wrote:

> If anyone here is interested in writing articles about FreeDOS,
> Opensource.com is interested in running FreeDOS articles. I write
> articles for them sometimes, and the FreeDOS articles perform very
> well on the site. In fact, they recently listed FreeDOS among their
> list of "topics we're interested in for 2023." Also included in the
> list: conio and C programming.
>
> I can tell you the editors are very welcoming, which is why I continue
> to write articles for them. If English isn't your first language, and
> you aren't confident of your English writing skills, they can help
> with editing to make the final version really nice.
>
> Here's the list they shared, in case this inspires anyone to write an
> article:
>
> - accessibility
> - Ansible
> - apt
> - Awk
> - Bash scripting
> - Blender
> - C getopt
> - C Programming
> - Chaos Engineering for K8s
> - Compose Key
> - conio
> - Containers/Pods
> - cron
> - Curl
> - DevOps
> - DevSecOps
> - dnf
> - doxygen
> - Emacs
> - find command
> - Firewall
> - FreeDOS
> - GDB
> - GIMP
> - Git
> - GNOME
> - GNU Screen
> - Go Beginners
> - Grep
> - Home Automation
> - Inkscape
> - Intro Small Scale Scrum
> - Java
> - JavaScript
> - Jinja2
> - Jupyter
> - Kdenlive
> - Kubectl
> - Kubernetes
> - Kubernetes SRE
> - Linux Apps
> - Linux perms
> - Logrotate
> - Markdown
> - MySQL
> - Networking
> - Parted
> - Pygame eBook
> - PyPI
> - Python
> - Raspberry Pi
> - Running K8s on RPi
> - Rust
> - Sed
> - SELinux
> - SSH
> - sudo
> - sustainability
> - systemd
> - tmux
> - Vim
> - wget
>
> Email the editors at o...@opensource.com
>
> They have a "write for us" page at https://opensource.com/writers
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] FD-KEYB issue tracking

[Aitor Santamaría]

Hello,

For a time now, we have the FreeDOS source archive allocated in GitLab:

FreeDOS Archive · GitLab 


I generally encourage the use of issue tracking systems in all IT projects,
as a way to keep a unique repository of acknowledged issues, a roadmap for
features, and a way to channel user interests and thus invest time in what
really matters, and that includes the FreeDOS project.

For FD-KEYB, I am really grateful if you use the issue tracker in GitLab:

Issues · FreeDOS Archive / Base / keyb · GitLab



I have been using it to track issues and new feature requests, and you are
encouraged to register your own. Currently, there are 7 open feature
requests that I have collected both from past user feedback, and from my
own. I'd like to have all the ideas that you can come up with, no
restrictions. My only request is that before logging a new issue, please
make sure that the bug DOES occur in the latest version, or that the
feature is NOT present in the latest version (currently, FD-KEYB 2.11).

In addition, your comments are welcome, in order to see the real interest
in those. And at the same time, I encourage you to comment only if you have
a real interest in the feature, and explain why you find it important (real
user experiences or needs). After all, I rather spend time patching other
stuff like DISPLAY or EDIT that may have real issues, than programming KEYB
features that are not too interesting.

Finally, I have moved all the issues and features for KEYB that I found
relevant/valid from the old FreeDOS bug tracker at SourceForge (they start
with #N, being N the issue id in the Sourceforge tracker). I am no longer
tracking issues for KEYB in SourceForge. Please use the GitLab tracker, so
don't be surprised if I disregard tickets in Sourceforge.

(for the freedos-devel folks, I have just announced FD-KEYB 2.10/2.11 in
the freedos-user mailing list)

Thanks,
Aitor

PD: I will do the same on DISPLAY and EDIT in the future, but don't expect
that in a time soon.
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] NEW KEYB 2.10 release

[Aitor Santamaría]

Hello,

A quick update: thanks to Fritz Müller, we now have message catalog in
German, in FD-KEYB 2.11:

KEYB 2.11 release · FreeDOS Archive / Base / keyb · GitLab
<https://gitlab.com/FreeDOS/base/keyb/-/releases/KEYB-2.11>

Thanks Fritz,
Aitor



On Wed, 16 Nov 2022 at 23:09, Aitor Santamaría  wrote:

> Hello,
>
> I have released the new FD-KEYB 2.10, packaged from GitLab and you can
> find here:
>
> KEYB 2.10 release · FreeDOS Archive / Base / keyb · GitLab
> <https://gitlab.com/FreeDOS/base/keyb/-/releases/KEYB-2.10>
>
> The most relevant change is the addition of the /CAPSLOCK=ON/OFF,
> /NUMLOCK=ON/OFF and /SCROLLLOC=ON/OFF switched, so that you can now use
> KEYB to enable/disable the lock keys (with no need to load a layout).
>
> As for the complete changelog:
>
>- Adds features for enabling/disabling the LOCK keys
>- Fix: Wrong memory allocation strategy parameterless
>- Adds: XT class PC fixes by Davide Bresolin
>- Fix: minor syntax corrections, to improve compatibility with
>FPC/16-bit
>
>
> The package does NOT follow the standard package format, as the GitLab
> release-making tool releases all the files under a folder "project-tag",
> and I do not know how to change that.
>
> I would appreciate it if you could test this release, as I have made
> several minor changes to improve compatibility with FPC (although it was
> compiled with TPC) and I would like to detect if I have broken anything
> within these changes.
>
> It is also packed with message catalogs for Spanish, French and Turkish,
> besides the default English catalog file.
>
> Please let me know of any unexpected behaviour.
> Aitor
>
>
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] NEW KEYB 2.10 release

[Aitor Santamaría]

Hello,

I have released the new FD-KEYB 2.10, packaged from GitLab and you can find
here:

KEYB 2.10 release · FreeDOS Archive / Base / keyb · GitLab


The most relevant change is the addition of the /CAPSLOCK=ON/OFF,
/NUMLOCK=ON/OFF and /SCROLLLOC=ON/OFF switched, so that you can now use
KEYB to enable/disable the lock keys (with no need to load a layout).

As for the complete changelog:
- Adds features for enabling/disabling the LOCK keys
- Fix: Wrong memory allocation strategy parameterless
- Adds: XT class PC fixes by Davide Bresolin
- Fix: minor syntax corrections, to improve compatibility with FPC/16-bit

The package does NOT follow the standard package format, as the GitLab
release-making tool releases all the files under a folder "project-tag",
and I do not know how to change that.

I would appreciate it if you could test this release, as I have made
several minor changes to improve compatibility with FPC (although it was
compiled with TPC) and I would like to detect if I have broken anything
within these changes.

It is also packed with message catalogs for Spanish, French and Turkish,
besides the default English catalog file.

Please let me know of any unexpected behaviour.
Aitor
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] DOS was dead...

[Aitor Santamaría]

Hi,

Ok sorry, got the reply later, and also the opinion I would vote for.

Aitor


On Thu, 15 Apr 2021 at 05:13, Jon Brase  wrote:

> >Apr 14, 2021 2:00:05 PM Ralf Quint :
>
> >And I stand by my comments that none of Windows 9x/ME is "running on
> DOS". I don't have the time right now to provide the detailed proof for
> that, but just look at the addresses of some of the DOS services before the
> booting of the Windows 9x GUI and afterwards (in a DOS prompt). They will
> be decisively different. You can install a TSR before the booting of
> Windows 9x GUI that redirects some of the DOS vectors to produce some debug
> output and you will not see that debug output when calling the same DOS
> vector while running under Windows 9x. That was also the problem with some
> DOS drivers for some SCSI adapters for example, which would not work under
> Windows 95, until the manufacturer provided a proper Windows driver for it.
>
> I will note that Windows 95 *could* use DOS drivers. I/O performance
> suffered horribly since DOS drivers weren't thread safe, but there was a
> copy of DOS in the system VM for this purpose, even if it had nothing to do
> under normal circumstances.


+1
For performance reasons, rewritten into VDOS, VREDIR, ... But DOS lies
still in every VM and its heart beats there.

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

Re: [Freedos-user] DOS was dead...

[Aitor Santamaría]

Hi Ralf,

On Wed, 14 Apr 2021 at 19:11, Ralf Quint  wrote:

> On 4/14/2021 8:54 AM, Liam Proven wrote:
> >
> >>   Reality is, Windows 95 dos and Windows 98SE DOS is not really dos per
> se
> > Wrong.
> Actually, in that part, Michael was correct. And as people like you seem
> to pushing that old myth of "Windows 9x runs on top of DOS", one of my
> next projects when I find time will be to come up with the definitive
> proof for that...
>

I am curious about this. What do you mean here? :)
In "Uncovered Windows95" precisely the opposite (WIndows 9X runs over DOS)
was proven by renaming COMMAND.COM to KRNL386.EXE...
And apparently Win32 applications run in VM0 with the "iddle call" beating
there.

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

Re: [Freedos-user] Print via USB

[Aitor Santamaría]

Hello,

On Tue, 20 Apr 2021 at 17:19, Frantisek Rysanek 
wrote:

> Built-in fonts are obviously an option, there's always some plain
> ASCII built in, and I believe in the old DOS era there used to be...
> programs that you ran before printing your jobs, that would
> pre-upload font sets or national character sets into the printer, so
> that your print jobs could then refer to those fonts and produce the
> desired output on paper.
>

DEVICE=PRINTER.SYS
MODE PRN CODEPAGE...
MODE PRN SELECT...

Creating a FD-PRINTER out of DISPLAY would not be hard.
The problem is that I don't have printer-specific language codes for
changing codepage that we would embed on a "printer-like CPI file". Such a
program would be the body of such a "CPI" file, and MODE would just let
PRINTER handle it.

Aitor


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

Re: [Freedos-user] DOSshell replacement

[Aitor Santamaría]

Hi Eric,

True! I forgot of Triple-DOS.
(Although I have not tried it myself).

Aitor


On Wed, 17 Aug 2022 at 21:42, Eric Auer  wrote:

>
> Hi Aitor,
>
> the topic reminds me that we have
>
>
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/triple-dos/
>
> in our archives - it is 20 years old and rather limited,
> but it might still provide some inspiration somehow :-)
>
> Regards, Eric
>
>
>
> > Under DOS-Shell, there was the DOSSWAP to do the task switching. But
> quite
> > a different approach from  multitasking, specially the preemptive way
> that
> > appeared with Win386 (the VMM).
> > Unfortunately, for the simplest (and useful) easier uses, I do not know
> of
> > a free DOSSWAP replacement. I assume that such software would make copies
> > of DOS and BIOS global variables (such as the list of lists) and swap
> them
> > upon a task switch.
>
>
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] DOSshell replacement

[Aitor Santamaría]

Hi,

On Wed, 17 Aug 2022 at 18:21, Bret Johnson  wrote:

> The first thing I think to note is that DOSShell was MUCH more than just a
> program launcher.  It include the same basic implementation and
> functionality that were in early versions of Windows (3.x) to perform
> task-switching.  With DOSShell, you could literally have several DOS
> applications running at the same time and switch between them with a few
> keystrokes.  This was similar to other task-switching programs from the
> same era, like DesqView and Software Carousel.  It sounds like that level
> of functionality is not required here.  I always found DOSShell to be
> "clunky" and even though I experimented with it a little I never really
> liked it for what I was trying to do.  I personally never tried any of the
> other task-switching programs besides DOSShell (and, of course, Windows).
>

Under DOS-Shell, there was the DOSSWAP to do the task switching. But quite
a different approach from  multitasking, specially the preemptive way that
appeared with Win386 (the VMM).
Unfortunately, for the simplest (and useful) easier uses, I do not know of
a free DOSSWAP replacement. I assume that such software would make copies
of DOS and BIOS global variables (such as the list of lists) and swap them
upon a task switch.

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

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

[Aitor Santamaría]

Hello,

On Wed, 17 Aug 2022 at 12:00, Liam Proven  wrote:

> On Wed, 17 Aug 2022 at 01:34, Wengier W via Freedos-user
>  wrote:
> >
> > 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.
>

Not actually. It may access the VxD virtual devices that do the real
hardware access in 32-bit, and are able to coordinate "multiple DOSes"
acceeding the same hardware (including "Windows", that is running in DOS
VM0).


> The 32-bit WinNT one can't: it's a sort of VM, containing a DOS emulator.
>
> The reason the NT one isn't very good is the reason that NT was a
> successful product: because it isolates apps from the hardware, making
> it more reliable and allowing SMP and things.
>
Actually translating BIOS and DOS calls to an OS that is not on the DOS
line, therefore doing not as good as VMM32.VXD (aka DOS386.EXE in previous
versions) and all its VxDs did in Windows 9X.


> Win64 drops 16-bit support. DOS is a 16-bit OS. It went along with
> 16-bit Windows support, no more and no less.
>
I think this is more realistically the real problem (not the graphics).
After all, we could still manage with DOS in a box, even if you can't
switch to full screen.

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

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

[Aitor Santamaría]

Hello.

On Tue, 16 Aug 2022 at 11:05, Liam Proven  wrote:

> I am puzzled: I mean, XP can run DOS programs directly, without
> assistance, can't it?
>
> Yes, on 32-bit versions of Windows (and I think this applies to Windws
Vista/7 at least), there used to be the NTVDM that  can run DOS programs
fairly well.
I used to test FD-KEYB there quite a lot, as in case it locks the console,
you don't need to restart.

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

Re: [Freedos-user] [Freedos-devel] mkeyb us: don't need a driver for US... BUT I AM NOT IN US!

[Aitor Santamaría]

Hello,

And there we go with the example I was referring to in my previous email:
the same language requiring two keyboard layouts (possibly two codepages
too).
Well, I seem to understand that your problem is with the installer: it
should have given you the option to choose Canada/French to use a
non-French/France layout.

If I took it wrong, and you wanted a "hot-switch" of keyboard layouts from
FR/whatever to US/no-driver, with FD-KEYB you can switch it off/on with
Ctrl+Alt+F1.

BTW, this mail sounds to me a bit more of a freedos-user email rather than
a freedos-devel email, so I am adding the other list too :)

Aitor







On Tue, 18 May 2021 at 15:59, Paul Dufresne via Freedos-devel <
freedos-de...@lists.sourceforge.net> wrote:

> Trying FC4 in QEMU on Linux with:
> $ qemu-system-i386 -enable-kvm -m 64M -cdrom FD13LIVE.iso  -hda hd.img
> -soundhw sb16 -boot c
>
> I have install to hard disk.
> Tried to choose Alternate-French for keyboard layout... I was expecting to
> choose Québec from a menu, but it continued to install.
>
> After installation it was in french. (AZERTY) which is painfull when used
> to QWERTY.
>
> I have tried, "mkeyb us" but it replied that I don't need a driver for US
> keyboard.
> BUT I AM NOT IN US, AND I WANT TO CHANGE BACK TO US!
> IT DID NOT LET ME DO IT.
>
> I had to edit FDAUTO.BAT, change mkeyb FR to mkeyb US (could have put it
> in REM)... then reboot to fix the problem.
>
> MKEYB US should change to US when you are not in US!
>
> I am not reallly angry... anymore. ;-)
>
>
>
> ___
> Freedos-devel mailing list
> freedos-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] For what architectures is FreeDOS designed?

[Aitor Santamaría]

Thanks for the hint.

Storage is cheap these days, I am just expecting that some information will
not expire.

Aitor


On Sat, 23 Jul 2022 at 22:09, Michael Brutman  wrote:

> This is an 8 year old email thread and you are expecting working links
> from back then?
>
> Regardless, archive.org is your friend:
> https://web.archive.org/web/20130430233113/https://geek.com/chips/nasa-needs-8086-chips-549867/
>
> Consider donating to them.
>
>
> On Sat, Jul 23, 2022 at 6:52 AM Aitor Santamaría 
> wrote:
>
>> The "geek.com" link mentioned looked interesting but is no longer online
>> (404), anyone knows where it went? (google is not giving me obvious answers)
>>
>> Aitor
>>
>> On Tue, 25 Nov 2014 at 10:38, ht-lab  wrote:
>>
>>> On 25/11/2014 00:57, Ralf Quint wrote:
>>> > On 11/24/2014 11:08 AM, Carl Spitzer wrote:
>>> >> Isn't the Z80 what the Space Shuttle and space Telescope used until
>>> >> the last decade. I seem to remember my old RS-4P was a Z80 chip. CWSIV
>>> > Nope, the Space Shuttle's main computer was from IBM, based on a
>>> > radiation-hardened version of a 32bit System/360 type CPU (just Google
>>> > "APA-101S")
>>> > And if you refer with "space telescope" to Hubble, that uses special
>>> > radiation hardened version of the Intel 80486...
>>> >
>>> > Ralf
>>>
>>> They used a whole range of processors including the 8086,
>>>
>>> http://www.geek.com/chips/nasa-needs-8086-chips-549867/
>>>
>>> Hans
>>> www.ht-lab.com
>>>
>>>
>>> >
>>> > ---
>>> > This email has been checked for viruses by Avast antivirus software.
>>> > http://www.avast.com
>>> >
>>> >
>>> >
>>> --
>>> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> > from Actuate! Instantly Supercharge Your Business Reports and
>>> Dashboards
>>> > with Interactivity, Sharing, Native Excel Exports, App Integration &
>>> more
>>> > Get technology previously reserved for billion-dollar corporations,
>>> FREE
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751=/4140/ostg.clktrk
>>> > ___
>>> > Freedos-user mailing list
>>> > Freedos-user@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/freedos-user
>>> >
>>>
>>>
>>>
>>> --
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751=/4140/ostg.clktrk
>>> ___
>>> Freedos-user mailing list
>>> Freedos-user@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>>
>> ___
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] For what architectures is FreeDOS designed?

[Aitor Santamaría]

The "geek.com" link mentioned looked interesting but is no longer online
(404), anyone knows where it went? (google is not giving me obvious answers)

Aitor

On Tue, 25 Nov 2014 at 10:38, ht-lab  wrote:

> On 25/11/2014 00:57, Ralf Quint wrote:
> > On 11/24/2014 11:08 AM, Carl Spitzer wrote:
> >> Isn't the Z80 what the Space Shuttle and space Telescope used until
> >> the last decade. I seem to remember my old RS-4P was a Z80 chip. CWSIV
> > Nope, the Space Shuttle's main computer was from IBM, based on a
> > radiation-hardened version of a 32bit System/360 type CPU (just Google
> > "APA-101S")
> > And if you refer with "space telescope" to Hubble, that uses special
> > radiation hardened version of the Intel 80486...
> >
> > Ralf
>
> They used a whole range of processors including the 8086,
>
> http://www.geek.com/chips/nasa-needs-8086-chips-549867/
>
> Hans
> www.ht-lab.com
>
>
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > http://www.avast.com
> >
> >
> >
> --
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751=/4140/ostg.clktrk
> > ___
> > Freedos-user mailing list
> > Freedos-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-user
> >
>
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751=/4140/ostg.clktrk
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] DOS ASM resources

[Aitor Santamaría]

Hello,


On Fri, 8 Jul 2022 at 01:28, Rugxulo  wrote:

> Hi,
>
> On Thu, Jul 7, 2022 at 5:53 PM Aitor Santamaría 
> wrote:
> >
> > On Fri, 8 Jul 2022 at 00:00, Rugxulo  wrote:
> >>
> >> I can send you my local copy (or show you how to get it) of the 3.2.2
> >> cross-compiler (i8086-msdos) that works under latest HX pre-releases.
> >> It has a built-in assembler and linker. It supports all memory models.
> >
> > THe links seem to work, why did you mention to send it? couldn't I
> download from that link?
> > And what do you mean that works under HX? I don't mind to compile under
> Windows11 or Linux if neccessary :)
>
> The Windows installer isn't DOS friendly. Besides, four target cpus
> with six memory models each is VERY bloated (especially because of six
> copies of huge "generics.ppu"). My local .7z of "8086 target only" is
> thus much, much smaller.
>
Ahh ok understood!
I'll gladly take it.


> But yes, it's meant to be a cross-compiler atop modern OSes. (Hey,
> since it still works under HX, I'll gladly use that.)
>
> > But I want it to run in 16-bit (Free)DOS.
>
> 16-bit host? No luck there.
>
No no, the assembled files to run under 16-bit :)

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

Re: [Freedos-user] DOS ASM resources

[Aitor Santamaría]

Hello,



On Fri, 8 Jul 2022 at 00:00, Rugxulo  wrote:

>
> > - Assembler - there is NASM, not compatible with MASM/WASM.  I guess
> there is still  (J)WASM as
> > alternative, as I assume that MASM/TASM haven't been neither open
> sourced nor actively maintained.
>
> Strictly speaking, OpenWatcom is "Open Source" (OSI) but not "Free
> software".

That is good enough for me :)
The best option for me would be MIT licensing, over the years I reached the
conclusion that it's the one that fits best my idea of open source software
(unlike GPL).

DeSmet C and IA16-ELF (GCC) both work fairly well (but not necessarily
> every memory model).
>
> * http://desmet-c.com/
> * https://github.com/tkchia/build-ia16/releases
>
> Thanks for the hints, specially the latter, that seems the same idea as
when FreePascal got the 16-bit flavour.


> > - Pascal: I admit I haven't tried FPC/16-bit yet, and see if I can
> happen to compile KEYB.  I am afraid it'll be hard
> > because the resident part of KEYB has a lot of assembler. TP/BP are now
> unmaintained (and not open sourced).
> > Similarly, if they close, we don't have an alternative 16-bit active
> open source Pascal compiler.
>
> * https://wiki.freepascal.org/DOS
> * https://sourceforge.net/projects/freepascal/files/msdos/3.2.2/


The Wiki sounds good to me!


> I can send you my local copy (or show you how to get it) of the 3.2.2
> cross-compiler (i8086-msdos) that works under latest HX pre-releases.
> It has a built-in assembler and linker. It supports all memory models.
>
THe links seem to work, why did you mention to send it? couldn't I download
from that link?
And what do you mean that works under HX? I don't mind to compile under
Windows11 or Linux if neccessary :)
But I want it to run in 16-bit (Free)DOS.

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

Re: [Freedos-user] DOS ASM resources

[Aitor Santamaría]

Hello,

I haven't been following much of what happens with the different assemblers
these days, but my idea is that the same thing as with C or Pascal happens:
as much as TASM or MASM are nice products, there are hardly open source
actively maintained products that are compatible with them, and hence NASM
can be an alternative.

I may be wrong but leaving aside smaller pet problems and trying to go for
broader products most widely used even by the FreeDOS community:

- Assembler - there is NASM, not compatible with MASM/WASM.  I guess there
is still  (J)WASM as alternative, as I assume that MASM/TASM haven't been
neither open sourced nor actively maintained.

- C: the only option seems to be OWC for 16-bit and with a good amount of
libraries. Apparently there's a community maintained what is called OWC 2.0
as the original project seems to be gone. If they close, I don't know of an
alternative 16-bit active open source C compiler.

- Pascal: I admit I haven't tried FPC/16-bit yet, and see if I can happen
to compile KEYB.  I am afraid it'll be hard because the resident part of
KEYB has a lot of assembler. TP/BP are now unmaintained (and not open
sourced). Similarly, if they close, we don't have an alternative 16-bit
active open source Pascal compiler.

What a sad panorama :)
Aitor








On Thu, 7 Jul 2022 at 18:42, Ralf Quint  wrote:

> On 7/2/2022 10:37 AM, Travis Siegel wrote:
> >
> > Masm, Tasm, and others all have their own syntax which confuses me
> > more than helping.
>
> Well, that is not quite correct. And it would be obvious if you did x86
> assembler in the early '80s. MASM (and basically TASM (as in Borland
> Turbo Assembler)) is using the same syntax as Intel is in their own
> assembler and in all Intel documentation. And that is the de facto
> standard for DOS x86. TASM "Ideal" mode is purely optional, with some
> good and some bad sides.  I commonly use the .MASM51 directive in all my
> assembler files, as that is the format that is most compatible with
> other compilers.
> And Turbo Debugger is hands down the best assembly language debugger, EVER.
>
> I tried to look at A86, but that is now so long ago that I don't recall
> right now what it was that I didn't like. I don't think that I spend
> more than 2 or 3 days playing with it.
>
> Similar with NASM, where for some weird reasons, they made the assembler
> case-sensitive, which I would consider utter nonsense (also among my
> griefs with C(++)). And it really bites you if you are trying to link
> assembler modules with other programming languages. It also
> (deliberately) doesn't support some assembler instructions (as per Intel
> specs) just because it doesn't fit into their parser (LODS, MOVS, ...),
> x87 registers are named differently
> And there are a lot more stupid changes that make it almost impossible
> to just compile/assemble older DOS related assembler sources without
> investing some additional time to do (error prone) conversions...
>
> Ralf
>
>
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] FD-KEYB bugs and features in GitLab

[Aitor Santamaría]

Hello,

For a time now, I have been collecting many ideas for possible enhancements
for FD-KEYB. I don't find any of them terribly necessary, that is why I
have never implemented them so far.

Being GitLab the official repository, I have opened several of them (those
that I found the most interesting) as "enhancement", so that anyone can
review, and maybe share opinions. Maybe, to my surprise, there are users
that would find them very important to be implemented, or maybe some of
them render not to make sense.

There are 9 enhancements, and 1 bug (the bug is already solved, I just need
to figure out how to pull it from Github to GitLab):

Issues · FreeDOS Archive / Base / keyb · GitLab


If you have comments or suggestions, or anything, please use GitLab itself
to comment on those, so that comments get registered with each feature,
much better than discussing here (pitty that apparently you cannot "vote"
for the features).

In addition, for those programmers willing to contribute: NONE of the
features are assigned (to me). This is an open source project, and the
sources are there: if you find the challenge appealing, and you are fluent
with Pascal, and even more important, with ASSEMBLER, feel free to assign
any of these yourselves, and set your hands to the source code  :)

And similarly, I encourage any user to add to GITLAB (not GitHub) new
features that you would like to see, either for KEYB or for any other
FreeDOS tool, so that we have a final repository of those feature requests.
But please, be very careful to open them as "enhancement" and not as "bug",
because we should clearly see what is something not working (that should
have a higher priority) from a new feature request.

Thanks in advance,
Aitor
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] DOS Fonts

[Aitor Santamaría]

Hello,

The graphic card maintains information of how character glyphs are made out
of their character code. Basically it is limited to being able to represent
just 256 characters together at a time (there is a trick to double this to
512, but doesn't make a difference here).

Each of such configuration set is called a codepage, and the different
codepages usually maintain the first 128 characters the same (ASCII),
whereas the other 128 characters are used to represent different characters
that may vary between countries.
Ideally, one could define different codepages that do not change which
character is represented, but the way the character is printed to screen.
But it is usually not the case: codepages usually have the same
"appearance" but different locale characters (at least in the characters
129-255).

Also notice that after screen resolution changes usually reset the original
codepage the BIOS came with (usually CP437, US-English), so your CP or font
is wipped out. This means that you'd need some resident code that would
restore your codepage after each time that resolution is changed.

This "screen" stuff is, in the end, part of the Console management. Thus,
it should be the responsibility of DOS' CON (console) devide. But as the
codepage change is very rarely executed (I assume) inside the US, this
particular resident code is not shipped with kernel's CON device, but you
have to enlarge your CON and load it yourself as you boot your PC.

SO, what are your options in FreeDOS? There are two options that I do know
of:
* DISPLAY is the standard DOS way of doing this (in MS-DOS, it is
DISPLAY.SYS, in FreeDOS it is DISPLAY.COM). You can try and create a CPI
file with your "font", and thus use standard (MODE CON...) mechanism to
load this font within DISPLAY. DISPLAY will guarantee that the font remains
after a change of resolution. In addition, this would be incompatible with
any DOS user that wants to actually change a codepage (and set, for
example, the standard western european with Euro CP858), unless you create
fonts for each of the codepages.
* There is GNU LOADFONT: you can create a font for GNU Loadfont, and load
it within a single executable. However, I am not sure that Loadfont will
help you keep your codepage on a resolution change (I believe it does not).
Also I ignore how loadfont deals with different codepages (I seem to
remember that some fonts have different configurations for different
codepages).

Aitor



On Wed, 15 Jun 2022 at 19:37, Ralf Quint  wrote:

> On 6/15/2022 10:30 AM, Daniel wrote:
> > Is anyone familiar with how DOS fonts work?
> >
> > There are some .com files that will change the original font with
> > another and ya can create your own.  I created a TI-99/4aA font to use.
> >
> > So how does it work?  Is the hardware font cached and the cache is
> > changed?  Some programs will revert back to the original font when
> > exiting back to DOS.
> >
> > Is there a location where one can read/write the font information?
>
> There is no such thing as a "DOS Font". Seriously!
>
> Any font functionality is totally dependent on the graphics card being
> used. Any attempts to (kind of) standardize the use of fonts (incl.
> modification) might be found in the description of INT 10h functions
> (BIOS Video interrupt) but pretty much all of those, beside some VERY
> BASIC stuff common on VGA adapters) is totally manufacturer dependent...
>
>
> Ralf
>
>
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Super Charging Windows 3.1 ?

[Aitor Santamaría]

My small contribution here: I've always found cool (but not tried myself)
the Calmira project: make your Windows 3.X look like Windows 9X, or even
WinXP:

http://www.calmira.de/

Have fun,
Aitor


On Thu, 9 Jun 2022 at 16:04, Martin Iturbide 
wrote:

> Hello
>
> I was wondering if you know some links, articles, hints about all the
> software and fixes that can be installed on Windows 3.1 .Like if someone
> did the exercise on how he will tune/pimp his own Windows 3.1 today.
>
> There are many articles on how to install Windows 3.1 plain and check what
> that OS offered at that time, but I can not find someone that recommends
> what patches and software to install today on it, or what was the awesome
> software for Windows 3.1 that we used to have in the past. Like if someone
> will try to bring the 16bit Windows to the max.
>
> Any ideas?
>
> Regards
>
> --
> Martín Itúrbide
> http://www.os2world.com
> mar...@os2world.com
> martiniturb...@gmail.com
> Quito - Ecuador
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] "The very weird Hewlett Packard FreeDOS option"

[Aitor Santamaría]

Hi,

On Wed, 18 May 2022 at 09:51,  wrote:

> On 17 May 2022, 18:21, perditi...@gmail.com wrote:
> > So yes there is work in the pipeline, but nothing coming soon or
> guaranteed
> > to be useful.
> >
> > Jeremy
>
> That is great to hear, as FreeDOS will otherwise be drifting away
> forever on real hardware, even more as it was before (when there still
> were EFI-CSMs). That HP uses Linux (or rather: has to use /something
> else/) to boot FreeDOS proves exactly that.
>

Some months ago we discussed about this very precise topic.
I particularly favoured for something like this: let Linux do the job to
adapt to new hardware and FreeDOS live in a emulated 16-bit
environment that real hardware no longer provides.
I am happy that HP proved it to be feasible.

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

Re: [Freedos-user] freedos 1.3 on vm or real machine

[Aitor Santamaría]

Hello,

in PO.KEY what I see is
26 + * !C5
in the common section (for every codepage). The second plane appears to be
AltGr | Shift

And 26 is in hex 1A.

File:Ps2 de keyboard scancode set 1.svg - Wikimedia Commons


In short: it should be AltGr  or Shift plus the key that seems to be on the
right of letter P.

Did it ever work on previous versions of KEYB or the layouts?

Thanks,
Aitor




On Fri, 11 Mar 2022 at 00:22, Joao Silva  wrote:

> Hello
>
> I have a question: on freedos 1.3 or 1.2 i can't write the * without going
> to the numeric keypad.
>
> KEYB PO,858
> available: 858, 850, 860
>
> also can't write: ã ä â á à
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Keyboard issue

[Aitor Santamaría]

Hello,

On Fri, 9 May 2014 at 18:21, Bret Johnson  wrote:

> If so, (or perhaps even if not so), you might try the MS KEYB program.  It
> completely replaces the BIOS keyboard driver.  None of the other keyboard
> drivers replace the BIOS like MS KEYB does, they just indirectly extend the
> functionality of the BIOS.  None of the other keyboard drivers I'm aware of
> are true replacements for MS KEYB.
>

FD-KEYB /9  does too.
But I made this optional/non-default, because I much prefer the other
approach (and has a lesser memory footprint).

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

Re: [Freedos-user] GNU Cobol in the FreeDOS ...

[Aitor Santamaría]

Wow.
Impressive, years after.

On Tue, 15 Mar 2022 at 18:27, Liam Proven  wrote:

> On Tue, 15 Mar 2022 at 05:54, dmccunney  wrote:
> >
> > (Just for the record, I don't think it's *possible* to implement .NET
> > under DOS. It assumes a multitasking OS with 32 bit or better
> > architecture.)
>
> You might be surprised. :-)
>
>
> https://www.hanselman.com/blog/net-everywhere-apparently-also-means-windows-311-and-dos
>
> https://github.com/MichalStrehovsky/SeeSharpSnake
>
> A Snake game in _8 kB_ of .NET code. But using custom libraries and
> disabling a lot of functionality.
>
> --
> Liam Proven ~ Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
> Twitter/LinkedIn: lproven ~ Skype: liamproven
> UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420)
> 702-829-053
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Speaking at FOSDEM'22 about DOS spreadsheets

[Aitor Santamaría]

+1

Lotus Improv was an underrated piece of software.

On Sat, 22 Jan 2022 at 13:00, Liam Proven  wrote:

> On Sat, 22 Jan 2022 at 00:44, Jim Hall  wrote:
> >
> > My topic is "A Brief History of Spreadsheets" and is a look back at how
> spreadsheets have evolved. Have you ever wondered why spreadsheets look and
> act that way? Why does LibreOffice and Excel use letters for columns and
> numbers for rows? That's what I'm discussing in this talk.
>
> Great! I will try to watch.
>
> I hope you can get Lotus Improv in there somewhere. The single most
> innovative program in that entire family I've ever used... but
> conceptually much harder than the simple grid model. A commercial
> flop, but an important design all the same.
>
> I have a new job and was too busy to prepare a talk. :-(
>
> --
> Liam Proven ~ Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
> Twitter/LinkedIn: lproven ~ Skype: liamproven
> UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420)
> 702-829-053
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
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

[Aitor Santamaría]

Plain right!
A LiLO that loads a small Linux distro which is multi-consoled, text-only,
and whose unique Shell is DOSEMU.
That would make it too, without the pain of writing VxDs, Linux will do the
job :)

Aitor


On Mon, 27 Dec 2021 at 18:58, tom ehlert  wrote:

>
> > 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
>
___
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

[Aitor Santamaría]

Hi,

On Mon, 27 Dec 2021 at 14:36, Liam Proven  wrote:

> On Sun, 26 Dec 2021 at 22:19, Aitor Santamaría  wrote:
> >
>
> > Why DOS386.EXE (later renamed to VMM32.VXD) would run "on top" of DOS
> and not be DOS itself, the natural way DOS adapts to a 386?
> > Just because, for commercial reasons, Microsoft never sold this DOS
> unbundled from their GUI, I don't see this to be part of Windows, but DOS.
>
> This is a red herring. It isn't what you think it is. It's not a
> multitasking add-on for DOS; it's a component of Windows.
>

I disagree.
In "Undercover Windows 95"  the author shows how you can rename COMMAND.COM
into KRNL386.EXE and actually have a DOS (not windows) with preemptive
multitasking and virtual memory. If I recall correctly, he builds a DOS
program that uses XMS to get memory, and DOS386 (or VMM32 if you like)
manages to give it more memory than the actual physical RAM memory the
machine had.
Not GUI (Windows) at all, just pure DOS.


> Windows has DOS multitasking long before Windows 3. There was a
> special 386 edition of Windows 2.01 that also could multitask DOS
> apps:
> http://oldcomputermuseum.com/os/windows_386_v2.10.html
>
> I think this is what I am talking about.


> > (and if it isn't, where is the technical limit? EMM386.EXE is more alike
> to VMM32.VXD than to MSDOS.SYS)
>
> But this is still Windows and not DOS. You are again confusing product
> lines.
>
> No, DOS multitasking was not some separate function that could be
> extracted from Windows and made stand-alone. It was an integral part
> of Windows right back to Windows/386. Windows 3 did not introduce
>

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.

Aitor
___
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

[Aitor Santamaría]

Hi,

On Sun, 26 Dec 2021 at 16:28, Liam Proven  wrote:

> On Sun, 26 Dec 2021 at 05:06, Jon Brase  wrote:
>
> > So if they lost the entire DOS-kernel Windows source tree sometime after
> the release of XP, the reason they're not releasing sources for Win 3.x/9x
> may be that said sources no longer exist.
>
> It could be. OTOH, there were multiple versions, and I'd be surprised
> if _all_ of them were lost.
>

It would be sad if it were true.
But I don't think so.  I've seen today that the whole of SIMTEL apparently
weights 10 GB.

I would dare say that even Bill Gates himself must have those sources
somewhere in one harddrive of his own (for historical purposes). :)

Aitor
___
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

[Aitor Santamaría]

Hello Tom,

I mostly agree with your arguments. However...

On Sun, 26 Dec 2021 at 01:42, tom ehlert  wrote:

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

Why isn't multitasking just another feature that you "add" on top? I mean,
from 1980 to 1998 DOS has been surprisingly surviving from a series of
innovations and obstacles that made it is what it is today (or was in 1998):
- A system that originally could do just FAT, created the redir (and later
ifs) to be able to mount other drives,
- A single user, to add share to be able to operate in networks,
- From 1 MB memory to higher with xms (HIMEM)
- From single tasking to preemptive multitasking (with DOS386.EXE)

Why DOS386.EXE (later renamed to VMM32.VXD) would run "on top" of DOS and
not be DOS itself, the natural way DOS adapts to a 386?
Just because, for commercial reasons, Microsoft never sold this DOS
unbundled from their GUI, I don't see this to be part of Windows, but DOS.

(and if it isn't, where is the technical limit? EMM386.EXE is more alike to
VMM32.VXD than to MSDOS.SYS)

My point here is, NT has indeed quite a bunch of more stable and better
thought features of an operating system that was conceived in the late 80's
rather in the late 70's (a better filesystem, more suitable to networks,
and basically, a brand new Win32 API more suitable for writing stable
applications), but I don't see multitasking as the feature that killed DOS.

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 :(

Aitor




>
> >> 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
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] reminder reminder?

[Aitor Santamaría]

Same here.

On Mon, 1 Nov 2021 at 19:22, Ralf Quint  wrote:

> On 11/1/2021 7:24 AM, Jim Hall wrote:
>
>
> Interesting. So far, Eric, Bryan, Angel, and Bonaventure received multiple
> copies (I'm assuming 3 for freedos-user and 3 for freedos-devel?) but I
> only received one.
>
> Any Gmail users out there who received multiple copies? My email is hosted
> by Gmail - I checked my Spam and didn't see anything, but I wonder if Gmail
> detected multiple copies sent and only delivered one to my Inbox.
>
> Nope, Gmail user here and got only one reminder, as usual...
>
>
> Ralf
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-6251705268808579447_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] MKEYB related stuff

[Aitor Santamaría]

Hi,

On Mon, 11 Oct 2021 at 22:18, Liam Proven  wrote:

> A question:
>
> Does the old MS-style
>
> [
> [CONFIG.SYS]
>
> country=044,437,c:\dos\country.sys
>
> [AUTOEXEC.BAT]
>
> keyb uk,437,c:\dos\keyboard.sys
> ]
>
> ... config still work? If not, would it work if the files were copied
> from MS-DOS or DR-DOS or something?
>
> If someone requires this level of configurability, then I guess it's
> necessary functionality.
>

Yeah, good to clarify. It does work (with either FD-KEYB or MKEYB).

The question in discussion here is: if you later want to change to, say,
codepage 850:
(a) with FD-KEYB, you issue KEYB UK,850,,C:\DOS\KEYBOARD.SYS  (no reboot)
(b) with MKEYB, you edit your AUTOEXEC.BAT and reboot

Discussing the usability of that (for how many users that's useful).

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

Re: [Freedos-user] MKEYB related stuff

[Aitor Santamaría]

Hello Eric,

On Mon, 11 Oct 2021 at 21:19, E. Auer  wrote:

> > Again, you're misunderstanding the problem.  You shouldn't just
> > automatically generate an ASCII 213 no matter what the Code Page is --
> > you should only generate an ASCII 213 when that's the Euro character
> > on the Code Page currently in use.  ASCII 213 is the Euro character on
> > some Code Pages (like 858) but not on others (like 437 & 850).  There
>
> That sounds like a lot of effort to disable a key binding while
> the user is not using the right font. Maybe they actually are
>
KEYB does it. But it's more of, you load one layout with or without that
binding.


> By definition, anything above 127 is not ASCII, so it will depend
> on the codepage. Still, it is extremely rare that people use more
> than one codepage on the same system AND have identical characters
> with different byte values depending on which codepage they use AND
> have keyboard drivers which support both BUT want to switch on the
> fly instead of using a boot menu option or a simple batch script to
> go to one of the codepage/layout combinations.
>
Define "on the fly". For me, on the fly is issuing a DOS command (such as
CHCP). I gave an example of why it would be desirable in the other thread.

The real solution for the whole mess would probably be to use
> Unicode and graphical fonts with a few 1 or more glyphs,
> but that would also be a very unlikely choice for DOS users ;-)
>
Well, imagine we have a FreeDOS version that will only run in a (say) 4 MB
minimum pentium+ VGA machine (not a big sacrifice this days).
You have lots of lots of memory. What you say is feasible (and very
desirable): a CON driver that would just switch to graphics mode, but
maintain a pseudo-text mode, emulating a text mode console (but maybe with
some IOCTL functions to write a image to same position). The Unicode glyphs
could be possible because they are (or many of them) stored somewhere in
XMS.

There you go an idea of how it could go. Wish someone had time to go for it
:)


> So while I can confirm that it is possible to design a problem to
> which your plan would be a solution, I still have big problems with
> the question "Will any user apart from yourself need anything even
> remotely as flexible as your planned inter-driver config signals?"
>
For the sake of MS-DOS compatibility. And for the sake of keyboard+screen
(=console) coherency.

Aitor
___
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

[Aitor Santamaría]

Hi,

On Mon, 11 Oct 2021 at 17:26, Bret Johnson  wrote:

> For older versions of FD-KEYB and KEYB programs from other places
> (including MKEYB),  I was thinking of maybe doing something with an
> Environment variable, similar to what FreeDOS has implemented with the
> COUNTRY environment variable.  I was thinking of an environment variable
> either called KEYBID or KEYBLAYOUT.  The contents of the variable would be
> the two-letter keyboard code followed optionally by the ID.  Some examples:
>
>   KEYBLAYOUT=US
> =US103   (same as US)
> =GR
> =GR129   (same as GR)
> =GR453
>
> With that, there is a way for a program to figure out what the current
> keyboard layout is if it needs to know for some reason (like some of mine
> do).  This variable could be set in the FreeDOS installation program or by
> the user if the user wants to "automate" things sufficiently.  I think
> adding the special FD-KEYB interface would still be valuable though, since
> it provides MUCH more information than just the ID.  The fact that it will
> rarely get used is not a valid reason to not implement it.
>

Well, everytime I see something like this you need (some information that
is retrieved within a single interrupt call), I always have the wild idea:
someone add an internal command to FreeCOM

C:\>KBLAYOUT
GR129
C:\>

unless someone builds up a clever DEBUG macro :)

You wouldn't have it on a variable though.
But I highly useful feature of FreeCOM would be precisely to store the last
line of an execution into a variable (unluckily we don't have `this` in
DOS):

SET /L  LAYOUT=KBLAYOUT

Anyway, ideas are cheap, how I wish I could put my hands on this myself :)

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

Re: [Freedos-user] MKEYB related stuff

[Aitor Santamaría]

Hi,


On Sat, 9 Oct 2021 at 20:02, tom ehlert  wrote:

> > 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 Á
>

What is a "keyboard code Á" supposed to be? KEYB gives a number, that can
be one or other character, depending on the codepage.


> > 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?
>
> No, the codepage change would happen rarely, because it should run
parallel to DISPLAY changing codepage. ANd the communication is
DISPLAY-->KEYB, not the other way round.
Only triggered by CHCP (or more incompletely, by MODE CON CP SELECT).



> 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?
>
Each layout (say GR) does only exist for several codepages (KEYBOARD.SYS
has the information for each such codepages for a layout).
On loading KEYB, it will determine if current codepage is suitable for that
layout, or refuse to load.
Similarly, when DISPLAY calls KEYB, KEYB may refuse to change codepage if
it doesn't have a suitable codepage configuration (although IIRC,
MS-DISPLAY.SYS seems to ignore KEYB and go ahead with the codepage change
in that case).

The key here is that for every configuration (like GR) there is NOT JUST
one  scancode->character mapping, but one mapping per codepage.


> > 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)?
>

Yes, it does. Because when the layout is loaded, it loads the information
for ALL suitable codepages for that layout.
The issue is raised from DISPLAY (or from whoever calls multiplexer,
AD81h,   Int 2F/AX=AD81h (ctyme.com) 
).

In fact, noone except for DISPLAY should raise that call: the screen may
render inconsistent, as you pointed out.

> 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.
>

Totally agree :)
But would be a nice to have (when I run Norton Commander, I could sacrifice
extended characters and change to 437).

 > 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.
>

But the keyboard driver is part of it, because it is part of the Console,
and does the magic (reason why DISPLAY calls it).


> >  Another popular,
> > memory saving, but inconsistent manner: issue a MODE CON CP SELECT.
> not a keyboard driver problem either.
>
Again CON=DISPLAY and DISPLAY calls KEYB.
As said, DISPLAY should refuse to change codepage if KEYB does not (but I
seem to remember that MS-DISPLAY ignores the answer from KEYB and goes
ahead).


> > 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.
>
Well, it's not a problem. But a functionality.
The ability to do a hot-switch of codepages (by hot I mean via CHCP).

When you don't have that backdoor, the only way to change your codepages is
to edit CONFIG/AUTOEXEC and reboot.

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

[Aitor Santamaría]

Hello Bret!

On Thu, 7 Oct 2021 at 05:42, Bret Johnson  wrote:

> I was also looking at the source code for FD-KEYB, and it looks like you
> have provided several extended functions for INT 2F.ADxx that aren't listed
> in RBIL.  Would it be possible to add another one that would provide both
> parts of the keyboard ID?
>
> Of course, what I would really like is a way to determine the entire
> ASCII-to-Scancode map (or at least details on where the current keyboard
> map is different than a standard QWERTY layout) without needing to build
> lookup tables for every possibility, but that is probably not feasible.
>

Well, a summary for both: I was thinking of providing an interface to
actually return the KeybCB, you'd have all the information (but would be
given the chance to mess around with it) :)
With that you have the entire Scancode-to-codepage (rather than
ASCII-to-scancode).

Note that may take a while, I am not being able to program so actively as I
used to in the past. :(

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

Re: [Freedos-user] MKEYB related stuff

[Aitor Santamaría]

Hello,


On Fri, 8 Oct 2021 at 12:18, tom ehlert  wrote:

>
> >> 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 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.


> 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 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).

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.

When will the hot codepage change happen? The preferred way: the user
issues a CHCP DOS call and NLSFUNC is loaded. Another popular, memory
saving, but inconsistent manner: issue a MODE CON CP SELECT.
In both cases, CON (=DISPLAY) will try to change codepage on both screen
and keyboard, and will fail on keyboard if KEYB does nos implement the
call, thus leaving the system potentially inconsistent.

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.

Aitor
___
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

[Aitor Santamaría]

You can do "something" with FD-KEYB, but not easy.

First of all, you have to find the KeybCB (KEYB Control Block) which is
currently in use.
That's the tricky part, you have to find out in the memory data blocks
associated to KEYB.

Then, you can walk through the KeybCB structure:

 ---Header---
000  BYTE  Number of submappings (n+1) described in the block
   General submapping is counted, and is usually numbered as 0.
001  BYTE  Number of additional planes (m) that are globally defined for
   the whole keyb control block. The total number of planes is
   m+2 (there are two implicit ones, see TABLE 3)
   The maximum number of planes is 10 (that is, m=8)
002  BYTE  Character to be used as decimal separator character by
   the driver when using this layout.
   0 when the default character (usually .) should be used.
003  BYTE  Current particular submapping in use (1 to n)
004  WORD  MCB-ID of the KeybCB, only if the KeybCB resides in a MCB
   that must be deallocated if the KeybCB will no longer be
   used.
006  DWORD PTR=> Next KeybCB
   KeybCBs may be organized in a linked list, if the keyboard
   driver supports more than one.
   Set to 00:00 if there are no more KeybCBs.
010  WORD  ID Word of the current KeybCB (see ofs 012)
012  8 BYTES   0-padded string of the name with which the KeybCB has been
   loaded. It is usually a two-letter identifier, such as UK,
   GR or SP.
   KeybCBs are usually loaded as single "keyboard layouts"
   identified by a short string and an identifier word in case
   there are several models appliable to the same string ID.
   (for the identifier word, see ofs 010)

Aitor



On Thu, 7 Oct 2021 at 00:20, Bret Johnson  wrote:

> > 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.  And, the KEYB program should work
> with multiple code pages when it can.  If DISPLAY.SYS is installed, you can
> use INT 2F.AD00 and INT 2F.AD02 to detect the current Code Page.  If
> DISPLAY.SYS is not installed, you can use INT 21.6601.  If neither of these
> work, you should assume code page 437 (which is the default on most
> systems).
>
> DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to inform
> KEYB so it can change its mapping.
>
> > why would any other TSR need insight into KEYB installed/not
> > installed state or a pointer to private tables?
>
> Unless the tables are in a "public" format, the data contained in the
> tables is irrelevant.  E.g., MS KEYB and FreeDOS KEYB tables do not use the
> same format.  I'm not sure about any of the other DOS's out there, but
> wouldn't necessarily expect them to be the same as MS.
>
> 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.  That is, the program allows the user to
> provide an ASCII code as an input parameter (since ASCII is far easier for
> the user to enter than a scancode), but the program itself uses the
> scancode.
>
> 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.  So, it has
> internal tables of a bunch of different keyboard layouts so it knows how to
> "type" the different ASCII characters.  It would be nice if SCANCODE could
> somehow "ask" the KEYB program what its tables look like, but that's not
> really feasible.  I realize you may think "typing" scancodes may be a
> "silly" thing to do, but there are cases where it works and ASCII codes do
> not (e.g., SCANCODE is able to "type" into older DOS-based versions of
> Windows, and can actually "type" things like PrintScreen or Pause or the
> multimedia keys or the Sleep/WakeUp/ShutDown keys that some keyboards have).
>
> 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 

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

[Aitor Santamaría]

Hi,

On Wed, 29 Sept 2021 at 21:39, Eric Auer  wrote:

>
> This also relates to why your COUNTRY= line does not only
> mention a country (for example for knowing whether you use
> number style 1,000.00 or rather 1.000,00) but also mentions
> the codepage, which can be relevant for currency signs etc.
>
> However, the COUNTRY=... setting is something managed by the
> kernel. You do not need to load any drivers for it. It also
> controls things such as whether to expect Y/N or J/N for yes
> no questions etc. Of course, that only happens when the apps
> take the effort to ask the kernel which settings are active,
> many apps just do everything English USA style themselves.
>

Well, the codepage mentioned in COUNTRY does not force all device drivers
to call its codepage (NLSFUNC will).
You can specify a codepage in Country, but your display driver will still
be in the default codepage.

You always need some driver (at least DISPLAY) to do it right.

Ah, those good old days where you did not, and things like  "españa.txt"
would be seen as  ESPA¹A.TXT  and you wondered why.

Aitor
___
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

[Aitor Santamaría]

Hello,


On Wed, 29 Sept 2021 at 16:36, Eric Auer  wrote:

> Not sure what you mean by mkeyb.de and that
> Language: de,858 or sg,858 line? Might be a
> sort of config file for the config/autoexec
> creation mechanism of the installer, so I
> guess Jerome or Mateusz can tell us more?
>
>
I suppose he means about the specific codepage to be changed?

If you need to handle codepages, you need a keyb that does handle that. I
am not sure how MKEYB handles that, you may want to use (FD-)KEYB if the
codepage change will occur dynamically (e.g. if DISPLAY is used to change
the codepage), at the cost of being a bit larger than MKEYB,

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

Re: [Freedos-user] FSF

[Aitor Santamaría]

Hi,

>From all the posts I have read on this thread, this is my own favourite.
I mostly agree with what is being said by Dennis.


On Wed, 31 Mar 2021 at 07:05, dmccunney  wrote:

> 2. The FSF is increasingly *irrelevant*. Open Source has *won*. It is
>
long past the days when an advocacy organization was needed to promote
> it and make it acceptable.  *Microsoft* bought GitHub, for heaven's
>
+1


> "Open source is more bug free and secure because the code is open and
> anyone can look at it."  Is it?
>
+1


> Most of what is open source these days has long since ceased being
> something anyone will *pay* for. There's no reason not to open source
> the code, as it no longer has monetary value.  (Of course. good luck
> with support...)
>
+5


> Want to do the entire open source ecosystem a favor?  Do everything
> you can to get *rid* of the GPL and use a license that doesn't put
> roadblocks in the reuse of the code by other projects.  Outfits like
> Google are already in that camp.  They create and use an enormous
> amount of open source code.  Nothing licensed with the GPL is part of
> it.
>
> I have a fair bit of GPLed code installed here.  I have it because it
> does something I need done, and it's the only thing that does it.  If
> an equivalent tool was issued under a more permissive license, I'd
> switch in a heartbeat. (I consider the GPL to be the worst thing RMS
> did to computing.)
>
+5

Months ago I had been giving a thought about what is (to me) the desirable
and less troublesome license one could find, and I found the MIT license
the most satisfying: fair enough to recognise other's work minus the
nightmare of source compatibility. Maybe you guys have a different idea or
experience.



> Meanwhile, I'm beyond caring about Stallman or the state of the FSF.
> Both deserve whatever happens to them.
>
+5

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

Re: [Freedos-user] [OT] BIOS weirdness with SATA/IDE adapter

[Aitor Santamaría]

Hi,

On Thu, 11 Mar 2021 at 16:03, dmccunney  wrote:

>
> > (What's more, in my personal belief, the second most alive intelligent
> species after Homo Sapiens is one of them).
> (And the African Grey parrot is likely the bird
> you are thinking of.)
>
Right.


> But while they may have evolved into birds, they are no longer dinosaurs.
>
Aren't they? :)
Well, they say that this is not a bird
Ichthyornis - Wikipedia, la enciclopedia libre

But a modern goose is:
geese teeth - Bing images


Is there a frontier, or is it the mania of humans to put things in boxes?
This is a wave or a particle.
Windows95 is a seamless new operating system :)

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

Re: [Freedos-user] [OT] BIOS weirdness with SATA/IDE adapter

[Aitor Santamaría]

Hi,

Indeed the discussion became offtopic.
Eric incidentally hit a different sensitive spot of mine...  (sorry!)

On Wed, 10 Mar 2021 at 23:57, Eric Auer  wrote:

> If you are interested in alive dragons, visit a Komodo Dragon.
> Those lizards do have some dragon-like properties, but they are
> not dinosaurs either - too "modern" species for that.
>

Why wouldn't a dinosaur be modern?
We live surrounded by some extant 10,000+ species of them which have
adapted very well to modern times. I see and hear them every day, as most
of us folks on this list.
(What's more, in my personal belief, the second most alive intelligent
species after Homo Sapiens is one of them).

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

Re: [Freedos-user] New AMB based FreeDOS Help

[Aitor Santamaría]

Ok thanks!

On Wed, 24 Feb 2021 at 01:20, Jerome Shidel  wrote:

>
>
> On Feb 23, 2021, at 6:16 PM, Aitor Santamaría  wrote:
>
> 
>
>
> Hi,
>
> I am sorry that this has been probably mentioned in the past, but, how
> does one get from HTML files to AMB?
> Or does AMB have a format that does not originate on an HTML file?
>
> Thanks in advance,
> Aitor
>
>
> The current help files were converted from HTML to AMB be Mateusz. I don’t
> recall exactly. But, I think he wrote a simplified conversion program
> specifically to convert the help files. You’d need to get the details from
> him.
>
> I was making on a generic HTML to AMB converter. It is semi-functional.
> But, some things came up and pulled me away from it. I haven’t worked on it
> in months. Eventually, I hope to get back to it and finish it.
>
> :-)
>
> Jerome
>
>
>
> On Mon, 22 Feb 2021 at 22:44, Jerome Shidel  wrote:
>
>>
>>
>> > On Feb 22, 2021, at 4:40 PM, Jerome Shidel  wrote:
>> > The amp based …
>>
>> The AMB based …
>>
>> (I just love spell correction)
>>
>> :-)
>>
>> ___
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Windows 95

[Aitor Santamaría]

Hi,


On Fri, 12 Feb 2021 at 01:19, Adam Nielsen via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> > Well, this will be a spoiler of the "Unauthorized Windows95"  :)
> > Better read the book if you can, but here you go a summary.
> > I write it to try and clarify some misunderstandings on VxDs and why I
> > think they are great.
>
> Wow that was really interesting, thanks for writing it!  I didn't know
> most of that and will definitely look for a copy of that book if it
> goes into this level of detail.  Fascinating stuff!
>

Want more? I forgot to mention it provides Virtual Memory too.

The author writes a small DOS program that requests memory via XMS.
Then he takes a PC with 8 MB RAM, replaces "KRNL386.EXE" with COMMAND.COM,
so that when the PC starts, you get COMMAND running on VM0 inside a 32-bit
VMM world.
He runs that DOS program, and magic! The program is able to gather 12MB of
XMS memory.

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

Re: [Freedos-user] Windows 95

[Aitor Santamaría]

Hello Adam,



On Thu, 11 Feb 2021 at 12:41, Adam Nielsen via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> > Well, I tend to disagree with this, but by a semantic question :)
> > In my opinion, VMM32 and all the VXDs are DOS, not Windows.  They sound
> to
> > me like the natural evolution of EMM386.EXE.
> > For me, Windows starts with KRNL386.EXE, not before (or with WIN.COM).
>
> I'm not familiar enough with VXDs but do they for example use the DOS
> interrupt 21 to open files, or do they call a Windows API?
>

Windows API is far above this level.

Well, this will be a spoiler of the "Unauthorized Windows95"  :)
Better read the book if you can, but here you go a summary.
I write it to try and clarify some misunderstandings on VxDs and why I
think they are great.

Think of VMM32 as a 32-bit DOS implementation, where there are several DOS
VM's, and that allows preemptively multitasking between them.
(what's more, from Win95 onwards, it allows preemptive
multi-threading inside each VM, whereas Win3.X does not).  So it is like a
super-powered version of EMM386.EXE (apparently, in some beta versions of
Windows, VMM32.VXD was called DOS386.EXE).

And think of VxDs as its device drivers. VxDs are 32-bit replacement for
DOS and BIOS, providing the same DOS/BIOS interface for the different
virtual machines and making sure that the different VMs will not
collide with each other when using the same hardware.

Simplifying a bit, this "32-bit DOS" has its own "CONFIG.SYS", that is the
[386Enh] section of the SYSTEM.INI file (and this file has nothing to do
with WIN.INI). There you control (to some extent) aspects of the VMM
behaviour, and which VxDs are loaded (or at least some of them).

See  System.ini Options (archive.org)


Some VxD examples (if I recall correctly):
DOSMGR - provides DOS INT 21h API for each VM
VFAT - provides FAT/LFN for each VM
VREDIR - provides the DOS network redirector for each VM
VKD - provides keyboard interrupt management for each VM, and ensures that
they do not collide in the use of the keyboard
VCOMD - provides serial COM interrupt calls for each VM, and ensures that
they do not collide in the use of the serial ports
and so on.

They also have an additional 32-bit interface, which can be used by
applications on the VM. Unfortunately, I don't know of a good documentation
of these interfaces. See for example:

int 20 (ctyme.com) 

the functions are there, but no information of the input/output parameters.

Fully 32-bit programs, such as Microsoft Windows, can be written over the
VxDs. Thus, on Windows 3.X/9X/ME,  KERNEL(KRNL386.EXE) /USER/GDI/...  are a
VxD-based implementation of the WIn32 API.  Windows runs in the VM0, and
the Win32 applications use this Win32 API. And from Windows95 on, they
preemptively multitask with each other because VMM32 allows preemptive
multithreading (each Win32 application is a thread on this VM 0).

WIN.COM, or the DOS kernel of Win9X/ME (after processing CONFIG.SYS and
running AUTOEXEC.BAT on COMMAND), basically prepare DOS to enter the
protected mode, then load the VMM and the VxDs, and after that, once in
protected mode with the VxDs loaded, they look for a file called
"KRNL386.EXE" and run it. Here is where Windows really starts (and WIN.INI
is it's configuration file, until the registry came).

Whenever one of the running applications on one of the VM's (such as
Microsoft Windows) produces a critical failure, then VMM32 will abort the
application and show the Blue Screen of Death (BSOD). The funny thing about
this is that (in my view), the BSODs are not Windows: it is DOS (the VMM)
complaining that Windows had a bug and had to stop it. :)



> > > at least in the beginning, there existed SCSI drives without Win95
> > > drivers where the DOS driver was loaded in CONFIG.SYS. Win95 tried to
> > > detect these disks by bouncing protected mode INT13 to real mode
> > > INT13. if this came back unchanged, the 32Bit code was used - as
> > > intended in the first place. But still 16 Bit drivers had a chance.
> > >
> > Interesting, I didn't know this. Any other 16bit stuff that Windows was
> > forced to use?
>
> I recall that you could load any DOS driver in CONFIG.SYS and it would
> be used by Windows, but Device Manager would report it running in a
> slow "compatibility mode" and would urge you to get native Windows
> drivers instead.
>

This means that Windows has to switch to 16-bit to run this software, and
you'd better get a 32-bit driver.



> I think any DOS drivers would do this - e.g. input drivers, but I only
> ever saw it myself with storage ones such as for ZIP drives.  Usually
> you wouldn't install these as Windows came with native drivers for most
> hardware but if you used an old installer for Win3.1 it could
> mistakenly install them.
>
The VxDs (or the native Windows drivers) would do this job on 

Re: [Freedos-user] FYI: I'm speaking at FOSDEM'21 this weekend

[Aitor Santamaría]

Hello,


On Thu, 4 Feb 2021 at 23:19, Jim Hall  wrote:

>
>
> On Thu, Feb 4, 2021 at 3:44 PM Jim Hall  wrote:
>
>> [..]
>>
> And there are other "like to have" things that would be great to have in a
>> FreeDOS "2.0" like an alternative DOS command.com shell. I described
>> that here long ago, and on the blog - would love to have an expanded
>> command.com that uses a BASIC-like syntax but still maintains
>> compatibility with DOS BAT files. At the time, you pointed out that Windows
>> command.com did something similar to what I proposed - but I don't use
>> Windows so I wasn't aware of that.
>>
>
> For reference, this is the expanded "BASIC-like" syntax I mentioned in
> 2018. If any new developers would like to write something new, this would
> be an interesting challenge:
>
>
> https://freedos-project.blogspot.com/2018/08/expanding-freedos-commandcom.html
>
>
Well, dreaming a bit higher, I've always thought that a nice challenge
would indeed be going towards the so-called windows commands:

Comandos de Windows | Microsoft Docs

(change to your language, I seem to get that in Spanish by default)

at least in what they would make sense in a DOS world.

Way beyond that, PowerShell, at least in what refers to the basic operating
system stuff (files and such), and that may run in 16-bit with the obvious
limitations for pipes, as there might be no open source initiative to
create an environment where those may run (at least not that I know of).

By the way, and I am going a bit off-topic here and asking for help:
wanting to find a way to batch rename files using a pattern and sequence, I
came across this expression, that gives an idea of how complex this can get:

ls | %{Rename-Item $_ -NewName ("NewFileName-{0}.jpg" -f $nr++)}

and now the questions, I wasn't able to understand the  %{ }  and how does
$nr++ relate to {0}, what are these constructs?

Best and thanks in advance,
Aitor
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Windows 95

[Aitor Santamaría]

Hi,

On Thu, 28 Jan 2021 at 21:12, tom ehlert  wrote:

>
> > "MS-DOS 7.x" doesn't exist for all but the initial boot process. As soon
> > as the Windows 9x boot logo comes up, there is no longer any "MS-DOS
>
Well, I tend to disagree with this, but by a semantic question :)
In my opinion, VMM32 and all the VXDs are DOS, not Windows.  They sound to
me like the natural evolution of EMM386.EXE.
For me, Windows starts with KRNL386.EXE, not before (or with WIN.COM).

As I see it, for a marketing reason Microsoft wanted to sell MS-DOS and
MS-Windows together, reason why they put them on the same hard drive and
VMM32.VXD ends up calling KRNL386.EXE. If it called COMMAND.COM instead, we
could have had a nice preemptive multitasking, virtual memory MS-DOS 7.0.

> foundation" active. Read any Windows 9x undocumented/inside/etc book and
> > those will explain this in detail. If you open a DOS prompt from within
> > Windows 9x, it is not "DOS underneath" that is running, but Windows'
> > NTVDM process. The initial DOS kernel is no longer active.
> you are mostly, but not entirely right.
>

Well I think in the so-called DOS-based versions, it is not a "NTVDM
Windows" program that you see, but a true new (copied) DOS virtual machine
that is NOT running Windows (unlike VM 0, that is running Windows). In my
belief, NTVDM is a WinNT program.

a) at least in the beginning, there existed SCSI drives without Win95
> drivers where the DOS driver was loaded in CONFIG.SYS. Win95 tried to
> detect these disks by bouncing protected mode INT13 to real mode
> INT13. if this came back unchanged, the 32Bit code was used - as
> intended in the first place. But still 16 Bit drivers had a chance.
>
Interesting, I didn't know this. Any other 16bit stuff that Windows was
forced to use?


> b) programs doing direct I/O, like every COM handler *had* to do. this
> was entirely up to the DOS program, with no support from Win95.
>
Wouldn't VCOMD do this? (just asking).


> But in the end, Win95 was the most stable DOS  environment ever.
>
+100.

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

Re: [Freedos-user] Updates to the FreeDOS website?

[Aitor Santamaría]

Hello Jim,

One more idea:


On Sun, 24 Jan 2021 at 23:54, Jim Hall  wrote:

> *3. Make the front page more welcoming*
> The front page is a quick "landing page" for people to learn about
> FreeDOS. It's not bad, but could be better. I'm planning to embed the
> latest FreeDOS video on the front, since the videos are about *things you
> can do with FreeDOS* or *showing off neat features in FreeDOS*, so I
> think the video will help. I'll also make the screenshots smaller so they
> don't take up so much of the screen.
>

Why not add a link to one of those fancy HTML virtual machines? With a link
of "Try it now!".
I seem to remember there were several out there (I can't think of any, but
I guess you list folks can post your favourite).

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

Re: [Freedos-user] Full nroff-troff-TeX for FreeDOS

[Aitor Santamaría]

On Mon, 25 Jan 2021 at 00:34, Jim Hall  wrote:

>
>
> *On Sun, Jan 24, 2021 at 5:17 PM Robert Keys  > wrote:*
>
>> *Hi all:*
>>
>> *FreeDOS newbie here (hopefully not needing the ancient internet flak
>> jacket).*
>>
>> *I used to run CPM/DOS/*nix in the ancient days of punch cards, paper
>> tape, 9-track reelsm, and floppies of the 8-inch and 5.25 inch sorts.
>> Alas, when I retired first, many years ago, I was corrupted with that
>> Winblows thingie that seems to run rampant these days.  I have seen and
>> tried the FreeDOS 1.2 suite and would like to try the 1.3 when it is
>> finally out.  The FreeDOS 1.3 RC3 was pretty good when I loaded it up.  My
>> goal is to*
>> *recreate my old dos vi/nroff/troff/TeX suite on FreeDOS.  We had roff
>> and nro-ish things even on CP/M.  Vi did not come along well until Calvin
>> on dos.  We also had Elan's mostly complete nroff/troff.  TeX compiled
>> somewhat out of the box on dos but took forever to build.  It was a bit
>> primitive.  But, with a set of *nixy tools, it was a qood writing box, for
>> years.  My heart yearns for that simplicity, once again.  I have an XP 586
>> box that is ready for the recyclers.  But, it would be fun to slap a big
>> drive in it and try FreeDOS.  When I tried the writing tool set, it mostly
>> came up and ran, but troff crashed it.  I don't think it was out of
>> memory.  But, something was just enough off to stop it.  I would consider
>> groff and friends, if they are known to work.  I think the early versions
>> will.*
>>
>> *So, are there any good working sets of vi/nroff/troff/TeX that are known
>> to run well on FreeDOS 1.3?*
>>
>> *ManyThanks!*
>>
>> *Bob*
>>
>
>
> Hi Robert
>
> FreeDOS has lots of editors, including some "vi" clones. You may have to
> install these using *FDIMPLES* (the package installer) to get them, but
> you can try *Elvis* or *Vim*.
>
> We don't have a TeX/LaTeX system on FreeDOS, but I remember using *emTeX*
> on DOS long ago. You should be able to run this on FreeDOS.
>
>
And it is a pitty, would be most appreciated! In the past I used to have
lots of problems trying to have PostScript output viewers. If there were a
TeX distribution that would port for PDF and a PDF viewer for DOS, would be
very good news indeed (yeah I remember the old ACROREAD for DOS, but I
assume it is nowhere close to be opensource nor free software).

Best wishes with the port,
Aitor
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Reminder: virtual get-together on Sunday

[Aitor Santamaría]

If Goole didn't lie (or conspire), it is now (on a few minutes), right? :)

On Fri, 22 Jan 2021 at 17:25, Jim Hall  wrote:

> Hi everyone!
>
> A quick reminder that our next FreeDOS virtual get-together is Sunday, 24
> January, 2021 at 11am US/Central. Use your favorite timezone converter to
> find your local time.
>
> Just like last time, we'll hold the meeting via BlueJeans. (You can
> download the meeting client, or you can join from your browser without the
> client.)
>
> I'll share a link here (and on the website, and on Twitter, and on
> Facebook) when the meeting starts.
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] DOS software

[Aitor Santamaría]

Possibly interested here too! :)

On Wed, 30 Dec 2020 at 23:38, Jim Hall  wrote:

> I'd love to see a list! There's probably some books and software I'd like.
>
> Jim
>
> On Wed, Dec 30, 2020 at 2:30 PM Ray Davison  wrote:
>
>> I will keep DOS running primarily for accounting and word-processing,
>> because none of the "modern" apps have given me reason to change.
>>
>> However, I have about fifteen linear feet of software and third party
>> books that I may have used but mostly acquired because I thought it
>> might be useful someday - including a two pound, still skin-packed,
>> package to connect DOS to a 3270.
>>
>> I need the shelf space.  Does this stuff have any use to anyone?
>>
>> Ray
>>
>>
>> ___
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos V2.0 - when will it be available?

[Aitor Santamaría]

+1   to this idea


On 9 January 2013 at 20:54, Jim Hall  wrote:

> >> A hypervisor that can run dosbox and make modern hardware work
> >> with old dos programs anyone?  How about dosbox running on a Pentium 133
> >> or a Pentium 166 machine with 16 megs of ram?
> >
> > Insufficient demand to justify the effort.
>
>
> There may not be a lot of demand, but I see it as an interesting hack
> for someone to try.
>
> Actually, I proposed something like that a few years ago: create a
> custom Linux "spin" (mini-distribution) that boots a minimal
> environment, and starts up DOSEmu on virtual console 1, immediately
> booting a copy of FreeDOS. Maybe you can even provide the option to
> start additional DOSEmu+FreeDOS instances on the other virtual
> consoles, just by connecting to them and "logging in" (probably by
> pressing Enter).
> http://www.freedos.org/jhall/blog/?id=20090422-143518
>
> I don't know if it's possible to run multiple console DOSEmu instances
> on the same box, since I've only ever tried to run one (and XDOSEmu at
> that). Yes, that's overkill for booting DOS on a modern computer, but
> an interesting idea.
>
>
> --
> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> and much more. Keep your Java skills current with LearnJavaNow -
> 200+ hours of step-by-step video tutorials by Java experts.
> SALE $49.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122612
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
--
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS running on Linux

[Aitor Santamaría]

Hello Alain,

This idea of Jim's is what is closer to what I had in mind.

I don't know how good would DOS programs requiring VGA (such as games) run,
and in this case, I would find it more interesting to include X (or FLTK,
I'm not used to it).

Aitor

On 20 November 2015 at 20:51, Jim Hall  wrote:

> On Fri, Nov 20, 2015 at 1:10 PM, Georg Potthast
>  wrote:
> > Hi,
> >
> > I made a very small Linux distro called Nanolinux which is only 14 MB in
> > size:
> > https://sourceforge.net/projects/nanolinux/
> >
> > I could add Virtualbox to that and then you would get a bootable ISO with
> > about 50 to 70 MB in size that would run your DosemuLimpo
> >
> > (Although I did not manage to download that with the Firefox browser,
> > it does not recognize "ova" as a file extension. Maybe you put it into
> > a ZIP archive)
> >
> > Wonder if anybody would be interested to use this solution.
> >
>
> I, for one, would be very interested to see a text-mode "small" Linux
> that boots up an instance of DOSEMU instead of login on the first
> available virtual terminal. (I'd put a regular Linux login on the
> second VT.)
>
> This would provide an interesting "sandbox" to run Linux on new
> hardware. It would remove issues with hardware compatibility on newer
> systems.
>
> I don't know how small such a thing would be, but since it doesn't
> require a GUI (Nanolinux uses FLTK instead of X) and "only" needs to
> support DOSEMU, I imagine it would be quite small, probably smaller
> than the 14MB for your Nanolinux.
>
>
> jh
>
>
> --
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
--
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Mouse on a Dell laptop

[Aitor Santamaría]

Hi,

I have a DELL laptop, and haven't been able to se the touchpad: neither
CT-Mouse nor MS-Mouse seem to be able to detect it.

Does anyone have experiences to share?

Thanks in advance,
Aitor
--
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] iBiblio's Apache no longer provides directory listings

[Aitor Santamaría]

On this line: Windows' Explorer refuses to work with it, and actually says:

200 Type set to A
227 Entering Passive Mode

but fails to show the files (at leas on Win7). Firefox does it fine.

Aitor

2015-05-10 19:57 GMT+02:00 Mateusz Viste mate...@viste.fr:

  From the error message you give, I'd say that iBiblio might support
 only passive-mode FTP, and not the (legacy) active mode anymore.

 Most FTP clients have a configuration that allows to force them into
 either mode.

 Mateusz



 On 10/05/2015 19:40, Rugxulo wrote:
  Hi,
 
  On Sun, May 10, 2015 at 11:28 AM, Jim Hall jh...@freedos.org wrote:
 
  As a workaround until ibiblio fixes it, ftp access still works.
 
  ftp://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/files/
 
  On Sun, May 10, 2015 at 11:24 AM, Jim Hall jh...@freedos.org wrote:
 
  Rugxulo mentioned it to me yesterday. I don't know how long this has
 been
  going on. We're opening a ticket with ibiblio for them to fix it.
 
  Just to clarify, FTP works with something like Firefox but doesn't
  work (anymore) with mTCP's FTP (just tested, again, under VBox). This
  is some new change (regression?) as it worked fine until about a week
  ago. I don't know why, I'm far from savvy on networking. I haven't
  tried again (today) on other systems (e.g. jump drive with Ubuntu
  14.04.2), but it was giving me similar errors recently. Even Win7's
  FTP gives me an error Illegal PORT command just trying to do ls.




 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] iBiblio's Apache no longer provides directory listings

[Aitor Santamaría]

Yes, apparently it works now!

Aitor


2015-05-10 23:28 GMT+02:00 Jim Hall jh...@freedos.org:

 I'm on the road today, so I can't test. But I just got an email from
 ibiblio that says they fixed the problem for us. That was fast. Can anyone
 confirm? I won't be in a position to verify until this evening.
 On May 10, 2015 4:26 PM, Jim Hall jh...@freedos.org wrote:

 I think we might all calm down a bit. I appreciate the help in mirroring,
 etc, but ibiblio is usually good at responding to issues like this. But
 it's a Sunday, they will probably not see the ticket I entered until
 tomorrow.

 Also, Eric's index.html idea won't work, as I tried this test earlier.
 Their apache config isn't defaulting to index files on repositories.
 On May 10, 2015 1:55 PM, Eric Auer e.a...@jpberlin.de wrote:


 Hi Mateusz, others,

  This is known issue, that has been extensively discussed on the list...
 
 http://www.mail-archive.com/freedos-user@lists.sourceforge.net/msg15773.html

 Well if they think making directory listings on the fly takes too
 much CPU, we could make index.html files for OUR dirs, if we have
 lists of files, for example via FTP. Maybe somebody has a tool for
 this? I remember that making index.html for a local directory is
 not too painful with a bit of scripting, but never tried FTP :-)

 The idea is to upload fresh html files manually whenever contents
 of directories change. This will also allow FreeDOS branding :-)

 Regards, Eric




 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] deselecting localization features breaks installation

[Aitor Santamaría]

Hello Felix,

If you are still there, and this was not addressed, I recommend that you
log a bug at SourceForge to at least register this exists.

Thanks in advance!
Aitor



2012/9/16 Felix Miata mrma...@earthlink.net



 Last week I installed 1.1 from CD burned from downloaded iso. I deselected
 such localization features as keyb and nlsfunc and others I don't remember.
 The final stages of installation produced several screenfuls of the same
 localization error message that I no longer remember. The resulting
 fdconfig.sys was broken, producing no displayed menu, but waits on user
 input
 based upon the missing menu. I searched the bug tracker for the string
 fdconfig.sys and got 0 hits. Ordinarily I file bugs when I see things like
 this, but it's been a week and I don't remember details sufficient to make
 a
 useful report.

 [FDCONFIG.SYS]
 !COUNTRY=001,858,C:\DOS\BIN\COUNTRY.SYS
 !SET DOSDIR=C:\DOS
 1?DEVICE=C:\DOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
 2?DEVICE=C:\DOS\BIN\HIMEMX.EXE
 2?DEVICE=C:\DOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG
 3?DEVICE=C:\DOS\BIN\XMGR.SYS
 3?SHELL=C:\DOS\bin\4dos.com C:\DOS\bin /E:1024 /P:C:\AUTOEXEC.BAT
 4?SHELL=C:\DOS\BIN\COMMAND.COM C:\DOS\BIN /E:1024 /P=C:\AUTOEXEC.BAT
 12?SHELLHIGH=C:\DOS\BIN\COMMAND.COM C:\DOS\BIN /E:1024 /P=C:\AUTOEXEC.BAT

 install.log: http://fm.no-ip.com/Tmp/installlog-fd11-20120911.txt
 --
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)

   Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

 Felix Miata  ***  http://fm.no-ip.com/


 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://ad.doubleclick.net/clk;258768047;13503038;j?
 http://info.appdynamics.com/FreeJavaPerformanceDownload.html
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Please remove my email from this mailing list

[Aitor Santamaría]

Hello Jason,

There's a link at the bottom of each mail where you can find the mailing
list subscription options, where you can find the unsubscription option too.

If you have any trouble with it, mail us again please.

Aitor


2014/1/7 Jason Jantz jja...@prestressedconcreteinc.com

 Please remove my email from this mailing list.



 Thank you,



 Jason Jantz, P.E.

 Prestressed Concrete, Inc.

 2800 Old Highway 81

 Newton, KS 67114

 316-283-2277

 jja...@prestressedconcreteinc.com






 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] ...and about FreeCon this time

[Aitor Santamaría]

The problem is that there's a limit to what one can ask to a FreeDOS tool:
if it breaks MS-DOS compatibility. If DATE/T is taken as an option by
MS-DOS COMMAND.COM, so should FreeCOM. You don't know how many batch
programs could stop working with that change.

Aitor


2012/4/11 Zbigniew zbigniew2...@gmail.com

 2012/4/11, Tom Ehlert t...@drivesnapshot.de:

  2. Could it be made to use slash as separator in pathnames, just like
  4DOS allows both slash and backslash? Every Linux/BSD user will
  appreciate that.
  whats supposed to happen on
 
 C:DATE/T
  /T is probably an option
 
 DATE\T
  probably some program in subdirectory DATE shall be executed

 My personal vote would be for bringing a little more order, I mean: to
 suppress recognizing such input as option, if slash is directly after
 some string of characters - in such case path recognition should be
 assumed.
 --
 regards,
 Zbigniew


 --
 Better than sec? Nothing is better than sec when it comes to
 monitoring Big Data applications. Try Boundary one-second
 resolution app monitoring today. Free.
 http://p.sf.net/sfu/Boundary-dev2dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Programming languages in FreeDOS

[Aitor Santamaría]

As far as I know, it is just for assembler, not C... (but nice all the
same!).
I did some experiments in the past with Nomyso till JWASM appeared
(motivated by the fact that older JEMM only compiled under MASM).

Aitor


2012/4/11 Bernd Blaauw bbla...@home.nl

 Op 11-4-2012 20:25, Rugxulo schreef:

  (PS: If we have FreeDOS code that doesn't compile under OW I'd be
  interested in seeing it.  A few #defines can fix a lot of problems.  The
  debugging is the hard part.)
 
  There is a tcc2wat library by Blair Campbell on iBiblio, if anyone
  wants to take a look:
 
 
 http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/tcc2wat/


 http://www.devoresoftware.com/nomyso/
 was a script used for converting FD-EMM386's sourcecode back in the
 days. Might be usefull for other programs as well.


 --
 Better than sec? Nothing is better than sec when it comes to
 monitoring Big Data applications. Try Boundary one-second
 resolution app monitoring today. Free.
 http://p.sf.net/sfu/Boundary-dev2dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Long-term survival of FreeDOS

[Aitor Santamaría]

A yearly classic! :)
Well, I'm late, but by that time I'm sure that the question would
eventually arise again. I give my 2 c

I have been giving a thought about this for a while, and I think that part
of the problem is that is to be understood by DOS. I have two approaches
for the question:

* If by DOS you mean the ability to run DOS programs untouched from a
clean-booted PC, then in my opinion, the problem is not the processor
itself, but BIOS. Whereas other OSes like Linux or Windows have their own
HAL, DOS heavily depends on BIOS. Once 16-bit mode/emulation is removed,
and given that modern OSes use BIOS much less than DOS does, then if BIOS
is gone, the ability to boot DOS is gone. However, DOS can survive as do
those game-console emulators (a la MAME, nesticle, etc.), you distribute a
emulator to such simple machines (a 16 or 32 bit PC), with some BIOS, as
DOSEMU does, and DOS can survive there.
The drawback is that DOS will become a step for the freaks that want to
ever run those ancient apps. Younger generations haven't ever run them (or
now, for example, what lotus 1-2-3 or WordPerfect are).

* If by DOS you mean the ability to write simple programs on a well known
API (for programmers), or to run commandlines like (COPY F:\*:* G:), where
F: is an USB-attached encrypted partition and G: is a network attached
storage through WiFi, then I think the problem is smaller. In fact, 16-bit
simple apps are easily ported to 32-bit DOS (DPMI) where you just
translated your DOS API from a 16-bit to a 32-bit world, so going to a
64-bit platform, a POSIX platform, or even an NT plarform, that shouldn't
be a problem. Here DOS could survive as a complex kernel (e.g. a Linux
variant) on top on which there is just a POSIX-freecom and utils, and where
someone (3rd party/proprietary) could write simple apps that are not truly
realtime (after all, Linux is not DOS), but are can be quite fast, and
closer to hardware than any Java or Windows app would ever be.
The drawback is that, will this platform (the classic DOS API) be appealing
enough, as compared to directly write linux/posix apps on a simple kernel?

Now I wonder myself if any of these two variants will dominate in the
future, or if there will be a third different approach to the future of DOS.

Regards,
Aitor




2012/4/10 Alex alxm...@gmail.com

 Hi

 This topic is not about DOS vs other operating systems, or the fact
 that users tend to gradually abandon DOS. It's about the survivability
 of DOS vis-a-vis hardware.
 The starting point for my reasoning is: what will happen with the
 future development of the hardware architectures? So far DOS has fared
 relatively well, in the sense that it can still run even on 32bit and
 64bit architectures, despite the fact that it does not fully support
 them. Now the question is: will it always be like this? Or will there
 come a point when, due to a radical CPU redesign, we won't be able to
 even use DOS any longer on newer machines? What are the chances of
 this happening?

 Related questions are: how adaptable would the (Free)DOS codebase
 prove, in the event of this happening? How much manpower would be
 required to recode/adapt (Free)DOS to the new needs? In short, could
 DOS survive such a situation?

 I know that this may look as an overly pessimistic scenario, but I
 believe it's one we had better anticipate, rather than just assuming
 that things will always be as they are now. I hope I am very wrong in
 my reasoning, and I would be very glad if someone pointed it out.

 Cheers

 Alex


 --
 Better than sec? Nothing is better than sec when it comes to
 monitoring Big Data applications. Try Boundary one-second
 resolution app monitoring today. Free.
 http://p.sf.net/sfu/Boundary-dev2dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Need your comments about the FreeDOS site

[Aitor Santamaría]

Hi Jim

As you see, I am a bit delayed with mail.
The site looks very nice and neat now!!!

I was just wandering, whatever happened to those old technotes
(usually text or mail exceprts) that there used to be?

Aitor

2012/2/20 Jim Hall jh...@freedos.org:
 I am looking to make a few improvements to the www.freedos.org web
 site, with a focus on making information easier to find. I am looking
 for YOUR COMMENTS to help me. I'd appreciate hearing from GENERAL
 USERS and DEVELOPERS, pretty much anyone who uses the FreeDOS web
 site. This should take about 5 minutes of your time.

 Over the years, I often get questions from new users, asking Why
 FreeDOS? or Can FreeDOS do ___? These questions are answered in
 various places on the web site. Since people keep emailed me these
 questions, I think it's fair to assume folks aren't finding the
 information they need. And with the release of FreeDOS 1.1, I'm
 getting more of these questions.

 I'm thinking about merging some content from
 www.freedos.org/freedos/about/ into the front page, and breaking out
 other content using a more easily-read style. But I need to keep the
 important stuff on the front page. For example, I think the developer
 news (Latest updates) needs to stay. Also, I'm wondering if the
 tabs on the top banner bar really need to be there, or if they're
 just confusing.

 My question is WHAT content are people looking for. That's where YOU can help:


 - Why do YOU visit the FreeDOS web site? About how often do you visit
 the web site?

 - What information are you looking for that you ARE ABLE to find?

 - What information are you looking for that you CANNOT find?

 - Is the web site navigation confusing, or does it make sense to you?

 - What do YOU think needs to be on the front page?


 Please email me off-list.

 Thanks!
 -jh

 --
 Try before you buy = See our experts in action!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-dev2
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Multimedia Keyboards and Mouse Scroll Wheels

[Aitor Santamaría]

Hello,

2012/2/15 Rugxulo rugx...@gmail.com:
 Hi,

 On Wed, Feb 15, 2012 at 9:38 AM, BretJ bretj...@juno.com wrote:

 I personally would like to see modern DOS applications (the few that are
 still being developed) support the multimedia keys, power management keys,
 and scroll wheels on keyboards and mice.

 (Deprecated XKEYB had some optional support for 0xE0 or whatever keys,
 not sure about current KEYB. TDE editor can optionally use the Win key
 to bring up the menu with alternate of Ctrl-'\' also. I know Eric Auer
 buys 102-key keyboards without the dumb Win keys.)

FD-KEYB does support it, in the sense that you can remap one of those
key to output a character, string, or one of the limited commands
(such as calling some interrupts, reset or power off). But the
question is how and where to implement the operations behind those
keys (such as play, pause, ...).. Just two notes on my to-do list
for KEYB:
- Remove current code for reboot/shutdown commands, calling something
like FDAPM instead (provided that FDAPM offers functions for this).
- As it is, if you remap power keys to power commands, you should have
to do it for any keyboard layout (or rewrite your layour and recompile
the KL file. I intend to enable keyb to use some KL as supplement of
other KL (in the sense that if the key doesn't get remapped with the
first layout chains to the second). This would enable users to add
such remappings on the fly and without any memory overhead for the
users that don't have such keys.

Aitor

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb

[Aitor Santamaría]

Hi,

old thread ;)

There were in the past conflicts with KEYB 2.00 and JEMM that were
apparently solved with KEYB 2.01.
The NOHI option mostly controlls KEYB access to XMS, but reading this
thread, and knowing what I fixed 2.00 to 2.01, I suspect JEMM may make the
DOS' memory allocation strategy functions less robust than they are with
other DOSes.
In case it helps JEMM...

Aitor

El viernes, 13 de enero de 2012, Ulrich Hansen uhan...@mainz-online.de
escribió:
 Am 13.01.2012 um 18:54 schrieb Bernd Blaauw:

 Op 13-1-2012 16:11, Ulrich Hansen schreef:

 Description: I have installed FreeDOS 1.1 with german language and
keyboard. If I boot (after a fresh install) with bootmenu option 1 (Load
FreeDOS with JemmEx) keyb will crash with the error message:

 Keyboard layout : C:\FDOS\bin\keyboard.sys:GR [858](3)
 Critical error: cannot allocate memory. DOS reported error: 8

 could you try adding /NOHI at your KEYB line please?

 Wow. This worked!

 In AUTOEXEC.BAT I have now a line:

 KEYB GR,,keyboard.sys /NOHI

 In FDCONFIG.SYS I went back to all the original settings of FreeDOS 1.1.
So the JemmEx line looks like this again:

 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG

 X=TEST is just a test for checking which UMB areas are (un)safe to use.

 Could you perhaps try adding X=TEST to option 2 (EMM386) ? See if that
 works. I've not been able to reproduce your case in VMWARE Workstation 8.

 X=TEST is originally in option 2. The lines in FDCONFIG.SYS (untouched
after installation) look like this:

 2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG

 So this is OK.

 I don't really understand why leaving out X=TEST in option 1 solved the
problem too. Testing the UMBs should lead to a more stable behavior of
JEMMEX.EXE. Instead it crashed KEYB somehow. It's odd but it's easy to
reproduce with any fresh FreeDOS installation on VirtualBox with the
default settings (and choosing german keyboard layout).

 Anyway, starting KEYB with /NOHI seems to be the more elegant and logical
solution.
 Thanks!

 If this could be the default in FreeDOS, I think it would help other
users. At least the german ones... ;-)

 regards
 Ulrich






--
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Aitor Santamaría]

Just as a curiosity. Aas my google searches in Spanish by default,
hours after the release, I have noticed that there are already two
sites having an article covering that already (I don't know either of
them personaly):

http://www.neoteo.com/freedos-1-1-nueva-version-del-dos-gratuito
http://www.gustavopimentel.com.ar/2012/01/freedos-ya-esta-disponible-la-version-1-1/

Cheers and congrats all for the great job!!
Aitor


2012/1/3 James Hall jh...@freedos.org:
 Would be interesting to get downloads statistics in order to know how many
 people around the world is following freedos development...


 I'll see what stats we can get from ibiblio. Been a while since I
 needed stats from them, but they do track it. At worst, I may have to
 wait until the end of the month to get monthly stats.

 -jh

 --
 Write once. Port to many.
 Get the SDK and tools to simplify cross-platform app development. Create
 new or port existing apps to sell to consumers worldwide. Explore the
 Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
 http://p.sf.net/sfu/intel-appdev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Announce: FD-KEYB 2.01

[Aitor Santamaría]

Hi,

As you may have seen at the freedos.org site, I have released FreeDOS
KEYB 2.01, which contains important bugfixes that make it more stable
than the original 2.00 was. Every FD-KEYB 2.00 user is recommended to
upgrade.

Thanks and let me know of any issue that you may come across,
Aitor

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Unicode

[Aitor Santamaría]

That should work, try it out and let me know.
There's a bug with strings that I am fixing already, though. If it
doesn't work, I'll have the 2.01 beta soon.

Aitor

2011/7/9 Henrique Peron hpe...@terra.com.br:
 Hi all,

 Still I think UTF-8 aware KEYB and DISPLAY together with old apps
 are still a lot more useful than any you always have to use 16 bit
 wide characters method which would only work with new apps at all.
 KEYB would need no changes, 2-char wide characters would be a String.
 True that not too comfortable to write the corresponding KL layouts,
 but still feasible.
 It means I can use !1, !2, etc... on KEY files and create strings.
 I see, according to documentation, that I can prepare up to 79 strings.
 I'd like to prepare a prototype brazilian keyboard layout and try it
 with Mined.

 I have just a question, Aitor - how to deal with dead keys and strings?
 Can the resulting combination point to a string?
 Just an example:

 26 !C1 (...) -- !C1 Pointing to acute-accent combinations in this case
 (brazilian keyboard)

 (...)

 [Diacritics...]
 ´ aá -- Here is my doubt - Could I make a!1?

 [Strings...]
 !1 Bytes_related_to_á_in_UTF-8

 Cheers,
 Henrique

 --
 All of the data generated in your IT infrastructure is seriously valuable.
 Why? It contains a definitive record of application performance, security
 threats, fraudulent activity, and more. Splunk takes this data and makes
 sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-d2d-c2
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] weird keyboard keys (was Re: Problem with USB keyboard in some computers)

[Aitor Santamaría]

Hello,

2011/7/7 Rugxulo rugx...@gmail.com:
 All keyboards aren't all the same, though, which is why it's best not
 to hardcode key settings or use anything too obscure. My old 486 had a
 Macro key (available to use in SETEDIT via included TSR), my P166 had
 a Turbo key (typematic rate?), my laptop doesn't even have Pause/Break
 nor SysReq (does any DOS software use that???) nor numpad (natch,
 though some few laptops do). And of course that makes things like
 Ctrl-Break or Ctrl-Alt-SysReq-R-E-I-S-U-B impossible!   ;-)   Oh, and
 Eric (Auer) only buys 102-key keyboards (no Win or Menu keys, which
 most DOS apps ignore anyways except TDE). I think (old) XKEYB allowed
 for some user-defined stuff for those keys (0xE0 prefix???), but since
 XKEYB is deprecated, I guess it doesn't matter here.

This should be possible with FD-KEYB too. The only xkeyb thing that is
not implemented is the so-called X-Functions, which allows your TSR
to do a CALL FAR upon pressing some key.

Aitor

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')

[Aitor Santamaría]

Ok, sorry, that's what I meant. That you find the chain at the List of
Lists, right?

Aitor

2011/7/10 Bret Johnson bretj...@juno.com:
 I'm curious, you check the LoL to get the pointers and override it?

 No, you just insert a new one with the same name in the Device Driver chain.  
 DOS always searches the chain in order, and uses the first one with the 
 correct name that it finds.  It doesn't actually know, or even care, where 
 the real one is.


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')

[Aitor Santamaría]

Hello,

2011/7/7 Eric Auer e.a...@jpberlin.de:
 Still I think UTF-8 aware KEYB and DISPLAY together with old apps
 are still a lot more useful than any you always have to use 16 bit
 wide characters method which would only work with new apps at all.

KEYB would need no changes, 2-char wide characters would be a String.
True that not too comfortable to write the corresponding KL layouts,
but still feasible.

As for DISPLAY: MS-DISPLAY is a true enhancement of CON, but
FD-DISPLAY is not (yet).
Appart from turning DISPLAY into a DOS device driver and override
kernel's CON, but not only IOCTL, but also write. However, it would
still let out:
- int 10h users
- direct video BIOS writers
but would be a begining. Am I letting anything out?

Aitor

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] [SPAM] Re: Basic networking abilities

[Aitor Santamaría]

Hi,

 [Sorry to Aitor Santamaria for hijacking his email address. Looks like you
 can't post to this list without subscribing or forging email headers so I
 chose the latter. Bye!]

Eric was right, wasn't me. Not my style to use harsh language. Just cowards do.

Cheers,
Aitor

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Code pages in dot-matrix printers

[Aitor Santamaría]

Hi,

What an interesting topic.
With the information above, one can easily write a new hardware
handler for DISPLAY, called EPSON or ESC, to control this (well, one
would usually write this printer-specific hardware handlers appart
from VGA/EGA, into a so-called PRINTER.SYS).


I had been searching for such info for a while, and was unable to find
it. More info about other printers is appreciated.

THANKS!
Aitor




2011/5/4 Henrique Peron hpe...@terra.com.br:
 That is the point, Marco - I am not interested on any particular
 documentation.

 I am interested on all of them. Any documentation, related to any
 printer, from any manufacturer. The idea is to provide as many encodings
 as possible, for FreeDOS.

 You see, I'm particularly interested on those hardcoded encodings
 available, precisely, through the configuration of those dip-switches.
 Not only Epson provided such feature on their printers. There were
 printers from Citizen and other manufacturers on those days which also
 had tables of characters hardcoded on them and available through
 combination of dip-switches.

 Thank you,
 Henrique

 Em 4/5/2011 08:26, Marco Achury escreveu:

 If you inform manufacturer and model is easier to find help.
 Many Epson printers use Esc/C control language, also I remember
 was possible to make a hardware config with litltle switches.


 El 04/05/2011 07:23 a.m., escape escribió:
 Hello Henrique

 I have an good-old dot-matrix printer, but unfortunately without any
 manual. But I think it's not a big problem, as in-printer codepage can
 be printed. Still I bet, that in this case there is only two options
 possible: cp437 or some slight variation of cp866. I will send you
 results as soon, as I can get some time to recover it from storage, set
 it up and print-out ASCII-chart.


 On 28.04.11 10:05, Henrique Peron wrote:
 Hi all,

 is there anyone out there which happens to have user guides/reference
 manuals of those old dot-matrix printers?

 If so, there are, in general, pages on those guides that show tables of
 characters (Code pages).

 My e-mail address is hperon AT terra.com.br ; in case someone wants to
 help me, I could be contacted through the e-mail address just informed.

 The idea is to convert all useful info into new codepages for FreeDOS.
 Let me mention two cases as examples: I've been looking (for a few years
 already) for the description of codepages 854 and 776.

 Thanks in advance.

 Henrique Peron


 --
 WhatsUp Gold - Download Free Network Management Software
 The most intuitive, comprehensive, and cost-effective network
 management toolset available today.  Delivers lowest initial
 acquisition cost and overall TCO of any competing solution.
 http://p.sf.net/sfu/whatsupgold-sd
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

 --
 WhatsUp Gold - Download Free Network Management Software
 The most intuitive, comprehensive, and cost-effective network
 management toolset available today.  Delivers lowest initial
 acquisition cost and overall TCO of any competing solution.
 http://p.sf.net/sfu/whatsupgold-sd
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



 --
 --
 +-+-+-+-+-+-+-+
 Marco A. Achury
 Tel: +58-(212)-6158777
 Cel: +58-(414)-3142282
 Skype: marcoachury
 http://www.achury.com.ve



 --
 WhatsUp Gold - Download Free Network Management Software
 The most intuitive, comprehensive, and cost-effective network
 management toolset available today.  Delivers lowest initial
 acquisition cost and overall TCO of any competing solution.
 http://p.sf.net/sfu/whatsupgold-sd


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

 --
 WhatsUp Gold - Download Free Network Management Software
 The most intuitive, comprehensive, and cost-effective network
 management toolset available today.  Delivers lowest initial
 acquisition cost and overall TCO of any competing solution.
 http://p.sf.net/sfu/whatsupgold-sd
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. 

Re: [Freedos-user] Code pages in dot-matrix printers

[Aitor Santamaría]

Hi,

2011/5/4 Henrique Peron hpe...@terra.com.br:
 Hallo Eric! Wie geht's, mein Freund? :)

 If I understood you correctly, by using FreeDOS GRAPHICS, I could send a
 codepage directly to the printer's RAM (naturally, one which wasn't
 already hardcoded into it). Am I right? It would be great. All the
 codepages which I *created* for FreeDOS could be sent to a printer that way.

No.That's not GRAPHICS' work, but PRINTER.SYS, a driver similar to
DISPLAY.SYS, but for which one would need to write a hardware-specific
handler, something like:

PRINTER PRN=(EPSON,,3)

It's just that someone woud have to write the ESC/c handler. In the
aforementioned pages, the programmer would have to find:
- code to select hardware predefined codepages (  ESC(t )
- code to load and select software loadable codepages  ( in  ESC(t 3 0
2 1 0  says uder-defined characters, so there must be a way).

 1) To find documentation on as many codepages/character tables as possible.

 2) To prepare the proper keyboards to work with them.

This should be transparent. Keyboard is related to CON only
(regularly, changing CON's codepage should call KEYB, although it
usually doesn't).
CHCP xxx
should be in charge of calling ALL the drivers (CON, PRN, ...) to
change the codepage of them all.

 3) In the case of languages for which there has never been support by
 the industry, I would create codepages for them.
     This particular step I have already taken to assist, for instance,
 all official languages of Russia's 21 republics and all official
 languages written with the latin alphabet on Oceania and Africa and
 several indigenous languages considered co-official on the Americas.

 5) Somehow send those codepages to the printers' RAM. (I'm aware that
 unfortunately not all printers might provide such a feature.)
     (At least in my mind,) this particular step would require some
 software to somehow analyze the codepages encoded into the FreeDOS
 codepage libraries (CPX files) and send the necessary info to the
 printers' RAM. Such step would naturally not be necessary to deal with
 regular codepages, like 858 or 808, but with the codepages I created for
 FreeDOS, all in the cp300xx range. This step would not be taken by me;
 I've been (for a few years already) looking for someone who would
 volunteer on that. Ideas are always welcome.

There may be a trouble here: the CPI/CPX files that you are used to
are all DISPLAY-SYS style CPIs.
PRINTER-SYS style CPIs may be different, I think you create those
DISPLAY-SYS style CPIs with some program, but is that program able to
create PRINTER-SYS style CPIs?

I suspect that for some printers, PRINTER.SYS does not have just data,
but also printer-specific code, that is bulk loaded into the printer.
It is not given that you can create a software to load one of those
DISPLAY-SYS style CPI files that you produce to a printer.

Aitor

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Code pages in dot-matrix printers

[Aitor Santamaría]

Hello,

2011/5/5 Eric Auer e.a...@jpberlin.de:
 I believe Aitor also wrote some tool long ago which works
 similar but for hardware TEXT modes: The tool reads the VGA
 hardware font and uses that when printing the text that you
 see on the screen in text mode, printing a picture of that.

I think you refer to one that didn't print, but created a BMP file out
of it (good enough for what I needed, even if it wasn't too complex).

 A third tool would be one which reads a text FILE or poses
 as a DOS printer device (like PRN or LPT1 etc) but then does
 not print the text as text. Instead, it would read the font
 of a codepage of your choice and send a picture of the text
 in that codepage font to your printer.

This would be a way to create printer hardware handlers: if you write
a way to send that picture to the specific printer: printing in
graphics mode, bypassing any ways of the printer to load and use
codepages.
Programmers are welcome, I will give as much help understanding
DISPLAY as needed.

 While I am not aware of a nice implementation of this idea,
 I once wrote a similar driver which hooked LPTn+1 (where n
 is the number of real printer ports that you have) and made
 graphical printouts of all text sent there using the VGA 8x8
 BIOS font to print huge amounts of text on one sheet of paper
 but at the expense that printing happens only every 3 lines,
 as I had a 24 pin printer at that time ;-) Of course this
 meant that only plain text could be printed to LPTn+1, and
 that you had to be careful printing to LPT1 while the tool
 was active because LPT1 was where the actual printer was.

If you can recover it, such driver can be created (so there would be a
binary PRINTER.SYS-style driver for FreeDOS).

      (At least in my mind,) this particular step would require some
 software to somehow analyze the codepages encoded into the FreeDOS
 codepage libraries (CPX files) and send the necessary info to the
 printers' RAM.

 That would be a relatively easy transform as far as I remember,
 the font encoding for sending custom characters was relatively
 straightforward. I think Nx8, Nx16 and Nx24 font sizes could be
 loaded, with some 8 to 9 and 16 to 24 upscaling done by the ROM
 software of the printer to work on 9 / 24 pin hardware modes.

 Also, N could be different for each character if you selected
 sending a proportional spacing font. As DOS codepages are made
 for VGA, which has fixed character sizes, you could only check
 whether characters have extra empty space at the sides and then
 condense that to say one empty pixel after each character, to
 automatically calculate a proportional spacing. Of course this
 has to be user-selectable if you implement it at all, otherwise
 ASCII arts and text screenshots would break. Those only work in
 fixed spacing fonts, obviously :-)

As said above, if you volunteer  (in assembler)

Aitor

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Code pages in dot-matrix printers

[Aitor Santamaría]

Well, as said, you can just concentrate on the printer-interfacing
stuff  (select hardware or software codepage, and load a character
table), all the rest is already done (DISPLAY). But not QBASIC, but
NASM   ;)

Aitor



2011/5/5 Henrique Peron hpe...@terra.com.br:
 Hi Eric,

 ok, so printing in graphics mode it is.

 Yes, it would be slow, but there would be no limitations. There would be
 no dependence on codepages, either hardcoded or not.

 Programming in QBASIC was a long time ago. I don't program on any
 language anymore for almost 20 years. It seems, then, that it is all
 about intercepting texts and calculating glyphs. It seems you have the
 knowledge for that. Would you be interested?

 Cheers,
 Henrique

 Em 5/5/2011 15:04, Eric Auer escreveu:
 Hi Henrique,

 I just read a PDF file Epson ESC/P Reference Manual. It explains that
 24-pin printers can receive definitions on 241 characters into its RAM
 but those 9-pin LX printers cannot. They can only receive 6 characters
 Well 241 is enough for normal purposes, control chars do
 not really need to have a shape which is visible on paper.

 But yes if you find a 9 pin printer in a museum, no font.

 Perhaps the idea (which is what I did once with a 9-pin Epson LX-800
 that I had) is to manipulate the printer head directly.
 That is simply called printing graphics :-p

 would force me to manually provide the data (through a TXT file) which
 would be sent to a printer through some program which would pose as a
 printer driver. I would like to elaborate more on this but...
 No, you can just intercept the text and calculate the
 picture based on a font in RAM. You could just use the
 font of DISPLAY or the VGA card to save some RAM, but
 of course the necessary transformation of formats will
 make this somewhat CPU-heavy and slow. You can put the
 font pre-calculated in printer data style in RAM which
 saves CPU work but uses more RAM. Or you can do as you
 suggest - use some tool which would work similar to
 font-prn fontfile.cpi 4242 sometext.txt where 4242
 would be the codepage number selected from the CPI...

 Cheers, Eric


 --
 WhatsUp Gold - Download Free Network Management Software
 The most intuitive, comprehensive, and cost-effective network
 management toolset available today.  Delivers lowest initial
 acquisition cost and overall TCO of any competing solution.
 http://p.sf.net/sfu/whatsupgold-sd
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

 --
 WhatsUp Gold - Download Free Network Management Software
 The most intuitive, comprehensive, and cost-effective network
 management toolset available today.  Delivers lowest initial
 acquisition cost and overall TCO of any competing solution.
 http://p.sf.net/sfu/whatsupgold-sd
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Code pages in dot-matrix printers

[Aitor Santamaría]

Hello,

2011/5/6 Henrique Peron hpe...@terra.com.br:
 The number refers to the hex code (Unicode). Naturally, every dot would
 be a 0 and every @ would be a 1; with a little math, we have pixel
 data for any printer.

 The following step would be to create association files. I would prepare
 them.

 Let's say that we would have a file called CP858.TXT, which would be
 checked by, let's say, PRINTER.EXE. There would be a line which would
 read:

 D5, 20AC

 Then, I would run
 C:\ PRINTER 858

 Now, PRINTER.EXE knows that it would have to check CP858.TXT. If, when
 intercepting data being sent to a printer, it receives byte D5h, it
 would send the glyph code 20AC from the text file I have here.

Be careful here. You're breaking the NLS system here. The way to make
everything in a consistent way is that any character-device (such as a
printer  LPT1, or the console CON) must be a DOS device driver that
accepts certain ioctl commands to change codepage. Thus, when you
issue

CHCP 858

all devices (console, printer, ...) change their codepage by the
kernel (the NLSFUNC extension).

The goodpoint by the CONSOLE is that there's an alternate way to
change the codepage via interrupts, thus you don't need to write a
device driver, but to have a TSR to do that (I guess that FreeDOS
NLSFUNC does use this interface for FreeDOS DISPLAY, which is
unstandard, but helps having a DISPLAY.EXE instead of a DISPLAY.SYS).

Unfortunately, no other character devices have such interrupt
interface that I know of. In order words, such software must be a true
DOS device driver (such as MS-DOS DISPLAY.SYS) and not a TSR (such as
FreeDOS DISPLAY.EXE).

Thus Henrique, the way you suggest breaks NLS compatibility in two points:
- By not being a true device driver, issuing CHCP 858 would change
codepages of all devices to 858, except for the printer: kernel
doesn't have a way to reach such PRINTER.EXE
- Even if there was that interrupt interface, it must be a resident
program: thus, if a program (other than COMMAND) issues a codepage
change command, it would work.

Of course, would be usefeul for a number of scenarios. But unlike on
MS-DOS, the way to change to 858 wouldn't be a plain CHCP 858, but
CHCP 858
PRINTER 858

(MODE CON CP SELECT 858 is the NOT recommended way)

Aitor

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user