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 :

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

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

[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] 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

Re: [Freedos-user] internationalization ... KEYB bug? ... i18n-DOS ... Greek, Esperanto ... kernel 2039

[Aitor Santamaría]

Hello there,

Sorry for this all delay...

With this all time since KEYB 2.0 was released, I have found / been
notified / etc a couple of bugs, and would like to do a new release
that fixes them all (if only I had so much time as I used to have). I
also wanted to do a FreeDOS 1.1-style packing (WITH sources), so I'd
have to look for the way it was made, and this all sort of things also
do not contribuite for a quick solution. I hope however to put it at
the top priority for this summer.

I would appreciate if you could isolate wether it is KEYB related or
DISPLAY related. What if you simply load DISPLAY and use MODE CON CP
to try and change? I say this because KEYB does not (yet) use XMS, but
DISPLAY does, and sounds af if it has something to do with it. So if
the bug is in DISPLAY, and you could let me know the exact test case
where it doesn't work, I would appreciate it.

Regards,
Aitor



2010/10/26 Rugxulo :
> Hi again,
>
> On 10/25/10, Rugxulo  wrote:
>>
>> Hmm, the KEYBOARD.SYS etc. files are all dated 2009. Not sure if or
>> why that would break anything, but you never know.
>
> Yeah, that was it, for some odd reason. Going back to kpdos25x.zip
> (2006) instead of 2009 update (kpdos26x.zip) fixed it, dunno why. So
> it's some weird incompatibility, I assume Aitor or Henrique can figure
> it out or explain better than I can.
>
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with USB keyboard in some computers

[Aitor Santamaría]

Hi,

Interesting thread, although I am a bit late.

2011/4/18 Bret Johnson :
>>> - MS-DOS keyb.com should be used instead of FreeDOS keyb.exe.
>
>> Of course we cannot do that because we have no license for that.
>> Can you be more specific? Are there any particular problems with
>> FreeDOS KEYB? Are you using the current version? I myself like
>> MKEYB by Tom Ehlert - fewer layouts and features but very small.
>
> The problem is that none of the KEYB "replicas" are fully functional 
> replacements for MS KEYB.  MS KEYB actually does two things.  The first is to 
> provide alternative keyboard layouts (e.g., the Brazilian layout that Marcos 
> uses and the German layout that Eric uses).  All of the KEYB replicas that 
> I'm aware of do this.
>
> The other thing that MS KEYB does is replace the hardware/firmware keyboard 
> BIOS with a new software keyboard BIOS.  NONE of the KEYB replicas (at least 
> none that I'm aware of) do this.
>

Interesting.
Besides the fact that there are a couple of bugs in FD-KEYB, that I
should be fixing this summer finally, this interests me.

The "standard" use of FD-KEYB, with lesser memory footprint, does use
INT 15h,  4Fh for its function (as I think mkeyb) does. But you can
install an alternative int 9h interrupt handler if you use the /9
option. It does NOT do all that the BIOS does, as in order to save
space, it only handles keystrokes that differ from the standard BIOS
(assumed "US") keyboard does. Also you cannot (yet) program the
keyboard layout to simulate some special keys that (de)activate the
BIOS flags, such as Caps/Num/Scroll lock, shift, etc. But I was
wondering what else may I be leaving out.

> I actually have several programs that simulate keystrokes (MOUSKEYS, JOYKEYS, 
> SCANCODE, and USBKEYB).  However, in order to simulate keystrokes properly, 
> the BIOS must be "compatible" with the keyboard simulation as provided by the 
> programs.  Some hardware/firmware BIOS's are compatible, while others aren't. 
>  If you don't ever use these programs, or if your BIOS is compatible, MS KEYB 
> is not needed.  However, if you use any of these programs, and your BIOS is 
> incompatible, you need to replace the keyboard BIOS with a new one that is 
> compatible.  MS KEYB does this, and is the only program I'm aware of that 
> does.

I am also curious to know, because I was thinking that by 3.0, I would
remove all the pre-AT stuff (for easier maintainance), and leave only
INT 15h,  4Fh stuff, but why would you want to "simulate keystrokes
properly"?

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] Problem with USB keyboard in some computers

[Aitor Santamaría]

Hello,

2011/4/18 Bret Johnson :
>> Also interesting that some BIOSes are not fully compatible with DOS
>> keyboard (layout drivers).
>
> The incompatibilities aren't related to the keyboard layout drivers as such.  
> They are related to the way my programs simulate keystrokes (the way the my 
> programs insert a value in AL when the BIOS issues an IN AL,60h to request a 
> scancode from the keyboard hardware).  What my programs do, in SOME cases, is 
> call the INT 09 code stored in the IVT with the CPU's trap flag set.  When 
> the INT 09 code issues an IN AL,60h OpCode, my programs skip over the OpCode 
> and instead insert the scancode they're trying to simulate into AL.  You can 
> download the source code for USBKEYB and review exactly how this works.  For 
> some reason, this doesn't work with all BIOS's.

Well, there is a IN AL,60h Opcode in FD-KEYB. I hope it does help
(with the /9 option).

>> If I had to guess, I would say MKEYB uses int 15 and KEYB uses 40:xx.
>
> I think a lot of KEYB programs use INT 15.4Fh.  I personally don't know of 
> any that use the BDA.  BTW, INT 15.4Fh will only work properly for certain 
> keys (the letter and number keys).  It usually won't work properly for things 
> like Ctrl, Alt, Shift, PrintScreen, Pause, number pad keys, etc., if anybody 
> ever wanted those keys to work differently than they normally do.

That's why I meant in my other mail, I haven't implemented (yet) the
"commands" to modify the BDA.

>> PS: For the KEYB issue, as probably only few BIOSes are affected,
>> some separate "proper int16 and int 15.4f implementation" driver
>> would be a good idea, I would not suggest to put that into a default
>> KEYB itself.
>
> It would certainly be possible to create a separate "INT 09 BIOS Replacement" 
> program, rather than including it in KEYB.  I do think the "appropriate" 
> place for it is probably in the KEYB program, though, just like the MS 
> implementation.  It could be an option that is only installed if the user 
> requested or some kind of auto-test determined that it would be beneficial, 
> though.

That's what FD-KEYB's   /9 option does.

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

-

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

[Aitor Santamaría]

Hi,

2011/5/4 Henrique Peron :
> 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 :
> 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 :
> 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 :
> 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

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] Unicode (It was 'Problem with USB keyboard in some computers')

[Aitor Santamaría]

Hello,

2011/7/7 Eric Auer :
> 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] weird keyboard keys (was Re: Problem with USB keyboard in some computers)

[Aitor Santamaría]

Hello,

2011/7/7 Rugxulo :
> 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]

I'm curious, you check the LoL to get the pointers and override it?

Aitor

2011/7/10 Bret Johnson :
>> Appart from turning DISPLAY into a DOS device driver and override
>> kernel's CON, but not only IOCTL, but also write.
>
> FWIW, you don't actually need to turn DISPLAY into a device driver in order 
> to replace/enhance CON.  You can do that with a TSR also.  See my USBPRINT if 
> you want an example of how -- it "replaces" the default LPT1-LPT3, adds 
> LPT4-LPT9, and even passes calls through to the old LPTx in situations where 
> that is needed.
>
> IMHO, TSR's have a lot of advantages over device drivers, and can still be 
> installed in CONFIG.SYS if you actually want/need to do that (with the 
> INSTALL= option).
>
>
> --
> 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] 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 :
>> 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

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

[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] 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 :
>> 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

Re: [Freedos-user] changing caps-lock

[Aitor Santamaría]

Hello David,

Sorry for being late in replying.

You could do partly of what you say, depending on what you want.

(1) In what respects to remapping CapsLock (or any other key), you can
do it with KEYB, as any key would have its own scancode.

(2) With KEYB you can program any key into doing something you want.
The standard behaviour is: produce a basic "scancode-character" pair
(the one that the console pics and you see). But there are several
other things that you can program KEYB 2.X to do (called "commands").
You find the whole list in the "commands.txt" accompaining KEYB, and
I'll give you some examples:
- produce a string (not only a character)
- issue INT 5h (print screen)
- start a diacritic sequence (when you want to produce é you do [´] then [e])
Unfortunately, if you want that some other key behaves as CapsLock
(i.e. toggles the appropriate BIOS memory flag), it is on the list,
but NOT (yet) implemented (commands 88 and 98).

If you want to use this, you'll have to write your own KEY file and
compile it (or modify one of Henrique's existing layouts).

I hope that all was clear, otherwise please reply.
Aitor



2011/12/7 David Griffith :
>
> Does anyone here know how I can change caps lock into another control key?
> Would it work for DOSBOX as well?
>
> --
> David Griffith
> dgri...@cs.csubak.edu
>
> A: Because it fouls the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> --
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of
> discussion for anyone considering optimizing the pricing and packaging model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
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 
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] Multimedia Keyboards and Mouse Scroll Wheels

[Aitor Santamaría]

Hello,

2012/2/15 Rugxulo :
> Hi,
>
> On Wed, Feb 15, 2012 at 9:38 AM, BretJ  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] 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 :
> 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] ...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 

> 2012/4/11, Tom Ehlert :
>
> >> 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 

> 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 

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

> 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=84349831&iu=/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=84349831&iu=/4140/ostg.clktrk___
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 

>
>
> 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=119420431&iu=/4140/ostg.clktrk___
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] 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] 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] 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] 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] 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]

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 32-bit

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] 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] [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] [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] 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] 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] 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]

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 hot-key

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]

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]

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.

Ai

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]

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

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]

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] 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] 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] 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] 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] "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] 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] 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

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

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,


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] 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&iu=/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&iu=/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] 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&iu=/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&iu=/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] [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] 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] 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] 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] 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] 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] 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] 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

[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] 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] 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] 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] 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] 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

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

[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] 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

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 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] 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 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] 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] International chacarters and Open Watcom

[Aitor Santamaría]

To display other character sets in your DOS console please check the
DISPLAY and MODE commands, that will help you on that. There are many
examples in the bootdisks to show how to use it.
I don't know which character set, just tell us which are the settings
of these programs in MS-DOS that you use, and we can tell you how to
write that in FreeDOS (almost the same).

Aitor


2006/6/15, Arkady V.Belousov <[EMAIL PROTECTED]>:
> Hi!
>
> 15-Июн-2006 00:52 [EMAIL PROTECTED] (Escorter) wrote to
> freedos-user@lists.sourceforge.net:
>
> E> Maybe it's a dumb question, but how can I enable the
> E> international character support in the Open Watcom compiler?
> E> In my program, I want to write a message to the screen with
> E> printf, but the special characters (like "щ" or "≤") are
> E> displayed as other ASCII simbols, or not displayed at all.
>
> This not relates to OW - if characters are not displayed (correctly),
> then this mean, that you not run program, which download required by you
> localized fonts.
>
>
> ___
> 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.0" in the news...

[Aitor Santamaría]

Hi,

> > DRDOS has DPMI.  I assume FD could if it doesn't.
>
> What is the exact technical reason you can't start WfW 3.11 from
> FreeDOS? Is it the DPMI thing or something else?

I haven't looked much into this topic, but it cannot be the DPMI, as
when you run "WIN" then Microsoft's nice extender WIN386.EXE or if you
prefer VMM32.VXD (I've always loved the Win95 beta name, DOS386.EXE)
starts.

I guess there's a good reason why MS-DOS responds to the DOS386.EXE
start broadcast (whereas FreeDOS doesn't).

> > For what this is worth, I am able to get FreeDOS with the Q stuff to run
> > on newer MBs - AMD 64 -that fail with DRDOS.
>
> Yes, FreeDOS is great on modern hardware.
>
>  > They don't like EMM386; DR
> > or FD.
>
> Yes, I've posted at great length about this in the past. I use UMBPCI at
> the moment.
>
> > 64 bit is a bit of a jump, but if you will settle for 32 bit - for now -
> > I think we did most of that, it's called OS/2,
>
> Ah OK! Maybe it's time to look again at OS/2.

Well, OS/2 was promoted as "better DOS than DOS", but I don't think
OS/2 is so well documented as to start Free-OS/2 (nice and interesting
attempt if you do :))

Aitor


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS, Borland's current status and Borland's DOS software

[Aitor Santamaría]

Hi,

2006/7/9, Arkady V.Belousov <[EMAIL PROTECTED]>:
> Hi!
>
> 9-Июл-2006 23:12 [EMAIL PROTECTED] (Wesley Parish) wrote to
> freedos-user@lists.sourceforge.net:
>
> WP> What I want to ask is, has anyone approached Borland about the possibility
> WP> of
> WP> releasing their DOS compiler and database products as Open Source?  I've
>
> I suggest, that releasing Borland _compilers_ as _open source_ (beside
> releasing as unpaid software) is useless - these compilers are (1) much
> outdated (in sense of modern language standards compatibility and supported
> target platforms) and contains (2) many bugs, whereas there are (3)
> free(dom) alternative (OpenWatcom, for example), which newer, less buggy,
> more standards compliant and more code-efficient.
>
> So, even if Borland releases their compilers as open source, this gives
> nothing useful. And even if they release compilers as free(dom) open-source,
> I doubt that someone (experienced) will spend they efforts to evolve them to
> something more modern.
>
> Database (Paradox) is another story.

Well, I disagree with you for the case of TurboPascal: at least there
would be ONE open source 16-bit Pascal compiler. For C/C++ I agree
that we are lucky to stick to OpenWatcom.

Aitor

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS, Borland's current status and Borland's DOS software

[Aitor Santamaría]

Hi Arkady,

TurboPascal is by far the most used Pascal dialect, even if not
standarized (and FreePascal followed the good work, much ahead of the
more standard GPC).
In fact, both FreePascal and Delphi has been ported to Linux (and
other platforms) so that you can create platform-independent apps (or
at least Borland say so, I have never tried that), so the language
itself is not that platform dependent (another story are the
libraries, but there's even a FreePascal's DOS unit in Linux).
Well, I don't expect an spectacular evolution in any 16-bit product
(except for FreeDOS), and we should be happy if OpenWatcom does not
give up the 16-bit line, but back to TP, one wouldn't be locked if you
come across one bug that affects you.

Aitor

2006/7/9, Arkady V.Belousov <[EMAIL PROTECTED]>:
> Hi!
>
> 9-Июл-2006 18:10 [EMAIL PROTECTED] (Aitor Santamarэa) wrote to
> freedos-user@lists.sourceforge.net:
>
> >> So, even if Borland releases their compilers as open source, this gives
> >> nothing useful. And even if they release compilers as free(dom) 
> >> open-source,
> >> I doubt that someone (experienced) will spend they efforts to evolve them 
> >> to
> >> something more modern.
> AS> Well, I disagree with you for the case of TurboPascal: at least there
> AS> would be ONE open source 16-bit Pascal compiler.
>
> Issue is, that TP is a Pascal dialect, nobody (including standards)
> compatible and nowhere standardized. This (missing standards and
> compatibility with standards) is especially important, because TP is highly
> tied to DOS (and slightly to 16-bit Windows) platform and, thus,
> non-portable to newer platforms. I think, this very highly decreases
> perspectives of TP (_if_ it will be released as free open-source) to evolve.
> If you not expect evolving, then why you need sources?
>
>
> -
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS, Borland's current status and Borland's DOS software

[Aitor Santamaría]

Hi,

2006/7/9, Arkady V.Belousov <[EMAIL PROTECTED]>:

> _If_ you persuade Borland to release TP as free(dom) software, and _if_
> you get maintain of it by you, and _if_ you will fix bugs in it - I will not

I am not the only one DOS Pascal programmer in the world.

> object for this. I only doubt that even if Borland opens its old software,
> then someone (experienced) will maintain (evolve) this heap of problems.
> Else, if you not expect evolution (and you satisfied by existing compilers),

Condition not met: there's no free 16-bit Pascal compiler (at least as
good as TP6/7, I doubt the download in the French page is legal, and I
seem to recall that Borland no longer retains ownerwhip over TP), so I
am not satisfied.

> then why you need their sources?

Aitor


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Russian by UTF-8 in FreeDOS?

[Aitor Santamaría]

Hi Arkady,

Here I am sending to you the links to the binary utilities, (both exec
and source) with the latest versions. Both have accompaining
information files.

Some KEYB documentation may deem a bit incomplete, the ability for
"hot switching layouts and/or codepages" (for example in Russian to
skip from Latin to Cyrilic alphabets) (and also the support for
Japanese keyboards) made things a bit more complex, and I know that
the KEYB data files documentation is definitely to be improved.

For the data files (that is, codepage files for DISPLAY, layout files
for KEYB), I let this to Henrique, who knows better than me.

Finally, I simply warn that DISPLAY 0.13 (forthcomming soon) has a
hard source re-structure and some rewrite, so if you plan to read
sources, I'd recommend to wait.

Latest DISPLAY (currently DISPLAY.COM) 0.12:
Source: 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/disp012s.zip
Binary:http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/disp012x.zip

Latest KEYB 2.0 pre-4:
Source: 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kb2pre4s.zip
Binary: 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kb2pre4x.zip

Latest KC (Keyboard Compiler) and KLIB (Keyboard librarian), to
compose binary layout data files and pack them, ver 2.00:
Source: 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kc200s.zip
Binary: 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kc200x.zip

Aitor

2006/7/9, Arkady V.Belousov <[EMAIL PROTECTED]>:
> Hi!
>
> 9-Июл-2006 16:15 [EMAIL PROTECTED] (Henrique Peron) wrote to
> :
>
> >> BTW, Henrique, may you give me links to all latest editions of these
> >> utilities and links to documentation for them (which not included into
> >> packages)?
> HP> Links for DISPLAY, MODE and any other FreeDOS program are found at the
> HP> FreeDOS website, as usual.
>
>  :(  Link to www.freedos.org is too generic. May you specify precise
> links to latest archives?
>
>

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] web site (was: Freedos Future)

[Aitor Santamaría]

Looks good!
Just a question of taste, I liked the older font better, but the rest is great!
Have you tried by chance removing the underscore of links in the new
version, to see how it looks like?

Aitor

2006/7/24, Jim Hall <[EMAIL PROTECTED]>:
>
> I've been doing a little tinkering with the web site design.  By the
> time we finally make our "1.0" release, I figured FreeDOS should have a
> somewhat sharper-looking web page.  Bob Stammers and I have been
> discussing a new look off-list, and I think it's pretty much ready.
>
> If you would like a peek at the new design, it's at:
> http://www.freedos.org/index2.php?css=http://hallx049.oit.umn.edu/temp/fd/005.css
>
> It has a modern appearance: clean, simple.  I hope it's not too boring.
> I'm open to final tweaks before this new version goes live, later this week.
>
> This is just the first in several goals.  I also want to re-do the main
> page to fix two other things:
>
> 1. Clean up the linkList.
>
> At first pass, I'll need to make my best effort to organize things as
> best I can, and later we'll try to do a kind of "card sort" exercise if
> I can gather enough volunteers.  At the least, I want to have links
> grouped for first-time / general users and for developers.  How I order
> the links, I haven't decided.  But I may re-use links in both sections
> ... that might be okay if I keep the link names the same (otherwise, it
> would get confusing.)  I'll also rename some link text from what we have
> now.  At a top-level, the headers will probably be grouped into two
> sections:
>
> Using FreeDOS
>link
>link
>link
> Developers
>link
>link
>link
>
>
> 2. Different content on the main page.
>
> For as long as I can remember, the FreeDOS front page has contained a
> list of news items.  That was appropriate when we were a bunch of
> developers, but it's not helpful to users who aren't familiar with DOS.
> So I'll likely move the news items to a "developers" page, or
> something.  The front page will be filled with a few paragraphs lifted
> from "About", and a few paragraphs lifted from (perhaps) "Download" and
> other parts of the site.  Not sure how I'll re-write that content.  But
> the key is, everything a new user needs to know about FreeDOS should be
> located on the front page.
>
>
> -jh
>
>
> --
> I'm sorry my president's an idiot. I didn't vote for him.
>
>
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Uninstaller?

[Aitor Santamaría]

MS-DOS does. I have never tried UNINSTALL, but perhaps it had saved
already the bootsector so that you can come back to normal.
Its pair is called DELOLDOS, which I suppose would remove that
bootsector. Just speculating, I don't think it would remove the files
(btw to Chris Evans: I would use DELTREE and not ERASE).

About languages: there's a software contribution HOWTO in the FreeDOS
documentation project.

Avoid even mentioning FORTRAN or COBOL. They should be banned.

Aitor


2006/7/30, Blair Campbell <[EMAIL PROTECTED]>:
> > Is there a program to uninstall FreeDOS? Or do I have to write one? If
> > the latter, which languages are "allowed"?
>
> Umm, how many operating systems do YOU know of that have uninstallers??
>
> --
> Fall is my favorite season in Los Angeles, watching the birds change
> color and fall from the trees.
>   David Letterman (1947 - )
>
> See ya
>
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user