from:"Aitor Santamaría"

Hi,

On Sat, 8 Apr 2023 at 13:19, Steve Nickolas  wrote:

> On Sat, 8 Apr 2023, Andrew Bird via Freedos-devel wrote:
>
> >  I think I can shorten the Spanish text, which fixes both the alignment
> > problem and the lack of a space. I'll send a PR but I'd be grateful if
> > somebody can check the text there as my Spanish is mostly beginner
> > level.
>
> es_ES in PC DOS 6.3: "Tamaño del mayor programa ejecutable"
> es_ES in MS-DOS 6.22: "Programa ejecutable más extenso"
>
> Don't know how useful that is to you, though.
>

Both sound fine to me. The PC-DOS way is how I would have shortened it from
the original, but the way MS did it is even shorter and sounds more
professional :)

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

Re: [Freedos-devel] Minor problems FreeDOS 1.3 (Spanish translation)

Hello,

On Sat, 8 Apr 2023 at 11:53, Andrew Bird via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

>   I think I can shorten the Spanish text, which fixes both the alignment
> problem and the lack of a space. I'll send a PR but I'd be grateful if
> somebody can check the text there as my Spanish is mostly beginner level.
>

I volunteer :)

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

Re: [Freedos-devel] Minor problems FreeDOS 1.3 (Spanish translation)

Right, that was the space I was missing.
There were two T-like characters there, does it not make it any better?

Aitor

On Sat, 8 Apr 2023 at 08:09,  wrote:

> Hi,
>
> > On Apr 6, 2023, at 5:44 PM, Andrew Bird via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
> >
> > Hi Aitor, Hi Wilhelm,
> >   Can you check if the package in FreeDOS 1.3 has the current
> translation from fd-nls? The reason I updated in fd-nls was that the
> Spanish was garbled. At this time I also added the UTF-8 in the hope that
> that would be considered the master and the cp850/858 could be converted
> from it as necessary.
> >
> > Andrew
>
> I just tested under T2303 (should be the same in T2304, would not hurt to
> test).
>
> The Spanish translation text looked fine.
>
> However, the line that says “Largest executable program size” is long in
> Spanish and there is no spacing before the size…
>
> Tamaño de programa ejecutable más grande626K (640,944 bytes)
>
> Also, the columns for “Largest are upper memory block” do not align with
> it.
>
> :-)
>
> Jerome
>
> >
> > On Thu, 6 Apr 2023 22:05:16 +0200
> > Wilhelm Spiegl  wrote:
> >
> >> Hi Aitor,
> >> I do not know who made the spanish translation, maybe Andrew Bird as I
> just noticed on the site, it is only one year old, creating a cp xxx and
> the unicode version was an idea of Berki, he started in about 3 years ago
> with this.
> >> I assume the translator started with Win cp 1252 or overtook it from
> Google translate or something like this, overtook the cp of Google
> translate and forgot to change to 858 first. this can happen in win or
> linux as you handle with two cp and unicode.
> >>
> >> https://github.com/shidel/fd-nls/blob/master/mem/nls/mem.es.UTF-8
> >>
> >> Could you please check the utf-8 version and tell me if it is okay?
> Then I could try to fix this and maybe other commands.
> >> Which characters are bad? Only T or others too?
> >> One more question, you meant "grande 606K" or "grande 606 KB" or a
> different version? in gr there is a space between value and KB too.
> >>
> >> Willi
> >> --
> >> Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.com
> Mail gesendet.
> >> Am 06.04.23, 21:18 schrieb "Aitor Santamaría" :
> >>> Hello,
> >>>
> >>> I've been trying FreeDOS 1.3, and found a couple of minor problems
> running it in Spanish:
> >>>
> >>>
> >>>
> >>> the non-standar-ASCII characters appear as preceded by a strange
> symbol for MEM, I wonder if they are really saved as 850/858 or are saved
> as Unicode or something else.
> >>>
> >>> Besides, I've always missed a space before the size of the largest
> executable
> >>> "Tamaño de programa ejecutable más grande_606K" (the _ should be a
> blank but is not there).
> >>>
> >>> I assume these two have to do with the Spanish strings for MEM, should
> I fill in a bug report for that, or is anyone taking care of translations?
> >>>
> >>> I also have a suggestion, applying to Spanish and probably to other
> western European configurations: 850 is used as default codepage. I suggest
> changing to 858, which is the SAME except that it has the euro sign, that
> you can neatly see in the screenshot above. This would apply to any
> configuration where 850 is used as default codepage.
> >>>
> >>> Thanks in advance,
> >>> Aitor
> >>>
> >>>
> >>> ___ Freedos-devel mailing
> list Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >
> >
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Minor problems FreeDOS 1.3 (Spanish translation)

Hello WIlhelm,

Sorry for being late.

On Thu, 6 Apr 2023 at 22:06, Wilhelm Spiegl  wrote:

> Hi Aitor,
> I do not know who made the spanish translation, maybe Andrew Bird as I
> just noticed on the site, it is only one year old, creating a cp xxx and
> the unicode version was an idea of Berki, he started in about 3 years ago
> with this.
> I assume the translator started with Win cp 1252 or overtook it from
> Google translate or something like this, overtook the cp of Google
> translate and forgot to change to 858 first. this can happen in win or
> linux as you handle with two cp and unicode.
>
> https://github.com/shidel/fd-nls/blob/master/mem/nls/mem.es.UTF-8
>
> Could you please check the utf-8 version and tell me if it is okay? Then I
> could try to fix this and maybe other commands.
>

I am not sure what you mean by "being ok". If you mean that it compiles
into a version that produces the right output, I cannot check (I'd need
time to download, compile, test I don't have an already compilation, as
I never did that before).
If you mean that the file has strange characters on the web, it does NOT.
If you mean that it is a full translation, it is not. There are MANY
untranslated lines.


> Which characters are bad? Only T or others too?
>
Yeah, it is that T-like character that appears in front of the Ñ and the
diacritic characters.


> One more question, you meant "grande 606K" or "grande 606 KB" or a
> different version? in gr there is a space between value and KB too.
>
At least I would put a space between "e" and "6" :)
As for the spaces between a measurement and unit: I would opt for a space
too: you say  "5 min" and not "5min"


>
> Willi
>

Aitor



> --
> Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.com Mail
> gesendet.
> Am 06.04.23, 21:18 schrieb "Aitor Santamaría" :
>
>> Hello,
>>
>> I've been trying FreeDOS 1.3, and found a couple of minor problems
>> running it in Spanish:
>>
>> [image: image.png]
>>
>> the non-standar-ASCII characters appear as preceded by a strange symbol
>> for MEM, I wonder if they are really saved as 850/858 or are saved as
>> Unicode or something else.
>>
>> Besides, I've always missed a space before the size of the largest
>> executable
>> "Tamaño de programa ejecutable más grande_606K" (the _ should be a blank
>> but is not there).
>>
>> I assume these two have to do with the Spanish strings for MEM, should I
>> fill in a bug report for that, or is anyone taking care of translations?
>>
>> I also have a suggestion, applying to Spanish and probably to other
>> western European configurations: 850 is used as default codepage. I suggest
>> changing to 858, which is the SAME except that it has the euro sign, that
>> you can neatly see in the screenshot above. This would apply to any
>> configuration where 850 is used as default codepage.
>>
>> Thanks in advance,
>> Aitor
>>
>>
>> ___ Freedos-devel mailing
>> list Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Minor problems FreeDOS 1.3 (Spanish translation)

Hello,

Sorry for being late in replying.
You are right: I saw a lot of untranslated lines there, it almost needs to
be retranslated.

Curiously enough, the most important lines that give most of the output are
translated, o you can't imagine how much it is missing by running the
program.

Aitor







On Sat, 8 Apr 2023 at 17:12, Wilhelm Spiegl  wrote:

> I just checked spanish nls and if saw it correct, the spanish nls version
> at shidel nls has a lot of english text inside, not only comments. so it
> will have to be overworked completely. is the text at shidel nls the
> correct one?
> I will try to check all german versions of nls asap as i noticed some
> reports that are two weeks old, asap means, german easter is longer than
> others, from friday till easter monday and I will see to find time.
>
> My personal main problem is that bug reports are sometimes at this forum,
> sometimes at gitlab or anywhere else. And user problems are often overseen
> over weeks. this is not user friendly.
>
> willi
>
> --
> Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.com Mail
> gesendet.
> Am 08.04.23, 12:23 schrieb Andrew Bird via Freedos-devel <
> freedos-devel@lists.sourceforge.net>:
>
>> Hi,
>>
>> On Sat, 8 Apr 2023 10:51:38 +0100
>> Andrew Bird via Freedos-devel 
>> wrote:
>>
>> > Hi,
>> >
>> > On Sat, 8 Apr 2023 02:05:53 -0400
>> > Jerome Shidel  wrote:
>> >
>> > > Hi,
>> > >
>> > > > On Apr 6, 2023, at 5:44 PM, Andrew Bird via Freedos-devel <
>> freedos-devel@lists.sourceforge.net> wrote:
>> > > >
>> > > > Hi Aitor, Hi Wilhelm,
>> > > > Can you check if the package in FreeDOS 1.3 has the current
>> translation from fd-nls? The reason I updated in fd-nls was that the
>> Spanish was garbled. At this time I also added the UTF-8 in the hope that
>> that would be considered the master and the cp850/858 could be converted
>> from it as necessary.
>> > > >
>> > > > Andrew
>> > >
>> > > I just tested under T2303 (should be the same in T2304).
>> > >
>> > > Translation text looked fine.
>> > >
>> > > However, the line that says “Largest executable program size” is long
>> in Spanish and there is no spacing before the size…
>> > >
>> > > Tamaño de programa ejecutable más grande626K (640,944 bytes)
>> > >
>> > > Also, the columns for “Largest are upper memory block” do not align
>> with it.
>> > >
>> > > :-)
>> > >
>> > > Jerome
>> >
>> > I think I can shorten the Spanish text, which fixes both the alignment
>> problem and the lack of a space. I'll send a PR but I'd be grateful if
>> somebody can check the text there as my Spanish is mostly beginner level.
>> >
>> > Andrew
>>
>> Actually the size/alignment problem seems to affect other translations,
>> at least FR, IT and ES:
>>
>> $ grep 2.10 mem/nls/mem.??.U*
>> mem/nls/mem.de.UTF-8:2.10:Größter freier UMB
>> mem/nls/mem.es.UTF-8:2.10:Bloque de memoria superior libre más grande
>> mem/nls/mem.fr.UTF-8:2.10:Le plus grand bloc de mémoire haute libre
>> mem/nls/mem.it.UTF-8:2.10:Dimensione massima di un blocco di memoria
>> superiore (UMB)
>> mem/nls/mem.sv.UTF-8:2.10:Största fria övre minnesblock
>> mem/nls/mem.tr.UTF-8:2.10:En büyük boş üst bellek bloku
>>
>> To me it looks like the mem program itself will need changing to allow
>> for the extra length strings.
>>
>> Andrew
>>
>> > >
>> > > >
>> > > >
>> > > > On Thu, 6 Apr 2023 22:05:16 +0200
>> > > > Wilhelm Spiegl  wrote:
>> > > >
>> > > >> Hi Aitor,
>> > > >> I do not know who made the spanish translation, maybe Andrew Bird
>> as I just noticed on the site, it is only one year old, creating a cp xxx
>> and the unicode version was an idea of Berki, he started in about 3 years
>> ago with this.
>> > > >> I assume the translator started with Win cp 1252 or overtook it
>> from Google translate or something like this, overtook the cp of Google
>> translate and forgot to change to 858 first. this can happen in win or
>> linux as you handle with two cp and unicode.
>> > > >>
>> > > >> https://github.com/shidel/fd-nls/blob/master/mem/nls/mem.es.UTF-8
>> > > >>
>> > > >> Could you please check the utf-8 version and tell me if it is
>>

Re: [Freedos-devel] FreePascal bug [off-list]

Hello,

As for myself, I attempted to compile FD-KEYB with FPC 16-bit, which I find
to be a good proof, as it has heavy parts in Assembler, other parts in
Pascal, and many procedure-type variables.

It helped me fix a couple of minor (almost cometic) failures in the code.
But I did not succeed. The problems came when mangling with
procedure/function-type variables especially with far/near procedures, etc.

I posted in the list, but I assume that DOS programming is not that
exciting these days. I tried to isolate the problem, but when requested to
post the whole program, I did not get any useful replies in the mailing
list, so I quitted.

Maybe to retry some day :)
(all the other corrections were pushed into the latest KEYB version).

Aitor





On Thu, 13 Apr 2023 at 02:46, Ralf Quint  wrote:

> On 4/12/2023 5:08 PM, Jim Hall wrote:
> > A user emailed me (late last year) with a bug/issue report on
> > FreePascal in FreeDOS 1.3. I was going to (finally) reply to say they
> > really should ask the FreePascal people about this, but I realized I
> > couldn't really make out what they were saying. This is the part of
> > their email that relates to the FreePascal problem:
> >
> >> I believe this is a Free Pascal issue because the short
> >> hello world test works, but if you decide to use any
> >> objects, the Video unit is completely missing.  There is
> >> reference to consolidation of the video functions but no
> >> references to where the the functions in that unit went.
> >> Actually as good as Free Pascal are, they are getting
> >> pretty sloppy with keeping their work updates current in
> >> their wiki.  There are a lot of circular references that
> >> are dead ends when it comes to useful information for
> >> experienced users.
> >
> > Not sure what this is talking about, but I'm not a Pascal programmer.
> > And their email kept going off onto tangents, so it was hard to
> > follow. Does this "bug report" make sense to anyone?
>
> Well, (s)he is rather thin on any details, but it sounds as if the OP
> expects that FreePascal is a drop-in replacement for Turbo-Pascal. Which
> it isn't.
>
> The 16bit x86 (DOS) version is a bit of a step child at FreePascal, and
> I am not sure how usable the latest version of this actually is. This is
> on my to-do list, unfortunately currently further to the end of that, to
> check and verify how much work it is to get old Turbo Pascal stuff
> working with the 16bit version. And the 32bit version (using the GO32
> DOS Extender) has also been behind the general development of FP, with
> some of the OOP stuff probably not applicable at all anymore.
>
>
> Ralf
>
>
>
> Ralf
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Minor problems FreeDOS 1.3 (Spanish translation)

2023-04-06 Thread Aitor Santamaría

Hello,

I've been trying FreeDOS 1.3, and found a couple of minor problems running
it in Spanish:

[image: image.png]

the non-standar-ASCII characters appear as preceded by a strange symbol for
MEM, I wonder if they are really saved as 850/858 or are saved as Unicode
or something else.

Besides, I've always missed a space before the size of the largest
executable
"Tamaño de programa ejecutable más grande_606K" (the _ should be a blank
but is not there).

I assume these two have to do with the Spanish strings for MEM, should I
fill in a bug report for that, or is anyone taking care of translations?

I also have a suggestion, applying to Spanish and probably to other western
European configurations: 850 is used as default codepage. I suggest
changing to 858, which is the SAME except that it has the euro sign, that
you can neatly see in the screenshot above. This would apply to any
configuration where 850 is used as default codepage.

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

Re: [Freedos-devel] DOS 44h (Get Device Information) - CD-ROM marked as remote?

2023-03-13 Thread Aitor Santamaría

Thanks (to both) for the answer,

Aitor


On Mon, 13 Mar 2023 at 22:45, Ralf Quint  wrote:

> On 3/12/2023 5:56 PM, Aitor Santamaría wrote:
> > Hello,
> >
> > A quick question, if I query device information on CD-ROM (int 21h,
> > AX=4409h), will I get that a CD-ROM drive is remote?  (bit 12 = 1).
> >
> > I am getting this under XP's ntvdm, and it sounds as a correct thing
> > (the filesystem is not FAT), but I would like to check in case someone
> > knows if this is correct).
> >
> Yes, as that call actually checks for the presence of the redirector,
> not specifically for a CD-ROM drive, for that, you would have to test
> for the existence of MSCDEX (or equivalent) via INT 2Fh, 150xh...
>
>
> Ralf
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] DOS 44h (Get Device Information) - CD-ROM marked as remote?

2023-03-12 Thread Aitor Santamaría

Hello,

A quick question, if I query device information on CD-ROM (int 21h,
AX=4409h), will I get that a CD-ROM drive is remote?  (bit 12 = 1).

I am getting this under XP's ntvdm, and it sounds as a correct thing (the
filesystem is not FAT), but I would like to check in case someone knows if
this is correct).

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

Re: [Freedos-devel] Free FDISK interim builds

2023-02-28 Thread Aitor Santamaría

Hi,

On Tue, 28 Feb 2023 at 20:31, Eric Auer  wrote:

>
> PS: Interesting that Bing ChatGPT answers Aitor using his own
> mails, does it at least include some thanks to the author? :-)
>

Lol it does not, but it links to the log of pages, etc. where it took the
answers from. That's how I found out...

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

Re: [Freedos-devel] IFS API

2023-02-28 Thread Aitor Santamaría

Hi,

On Tue, 28 Feb 2023 at 12:23, tom ehlert  wrote:

>  Hey!
>
>
> > As a matter of curiosity, given that we were unable to find a
> > precise answer to why Microsoft dropped IFS after MS-DOS 5.0
>
> to start with, your question is pretty much nonsense. IFS or the
> "networking redirector" was definitively there in MSDOS 6.2 and most
> likely in 7 (aka Win95).
>

Well it was strongly related but different, what went forward on 4.0 was
taken back on 5.0.


> >  I thought, why not ask ChatGPT (Bing) about that?
>
> in the meantime everybody should know that ChatGPT has a very
> convinced attitude telling nonsense. I think asking it to find new
> pointers is legitimate. Taking the answer for truth is not.
>

Although no new pointers seem to appear, it is nevertheless fun.
To me, it is like "UI interface for a search engine" 2.0

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

Re: [Freedos-devel] IFS API

2023-02-27 Thread Aitor Santamaría

Hey!

As a matter of curiosity, given that we were unable to find a precise
answer to why Microsoft dropped IFS after MS-DOS 5.0 (although we had
speculations), I thought, why not ask ChatGPT (Bing) about that?

The answer is quite curious (I can't send the image due to mailing list
size limitations, but here it is the text):

"Microsoft IFS (Installable File System) was a feature of MS-DOS 4.0 that
allowed third-party file systems to be used with MS-DOS. However, it was
not widely adopted by OEMs and had compatibility issues with some
applications. MS-DOS 5.0 dropped support for IFS as it needed more
conventional memory and focused on other improvements, such as memory
management, disk utilities, and a full-screen editor".

and it looks good, if it weren't because the main source for this answer
was precisely my own previous email message in this mailing list.

If asked THE SAME question (except that by accident I wrote "why" and not
"Why"), I got a different answer, and had to interact with it:

"I’m sorry, I couldn’t find any information about why Microsoft dropped
support for IFS after MS-DOS 5.0. Do you have any more details about what
IFS stands for or what it does?

>> IFS is a feature that allows third-party file systems to be used with
MS-DOS.

Thank you for clarifying. I found some information about third-party file
systems for MS-DOS. According to Wikipedia1, some examples of third-party
file systems are HPFS, NTFS, CD-ROM and network file systems. However, I
couldn’t find a clear reason why Microsoft dropped support for IFS after
MS-DOS 5.0. One possible explanation is that Microsoft wanted to promote
its own file system formats, such as FAT16B and later FAT3212, which were
more compatible with Windows and other operating systems"

Also sounds accurate.

So the conclusions of this experience for me are:
- The content was added fast to ChatGPT (this thread was recent)
- ChatGPT was mostly able to "understand" the question (as much as a
machine can "understand"), i.e. the algorithms are well tuned. And the
answers look sensible.
- Probably, there's no other information about IFS publicly available, so
this is all we can have.

I had hoped that there was some page that we weren't unable to find. Or
even it could have been better if ChatGPT had any access to information
from Microsoft that was not easily publicly accessible.
Neither seems to be true.

As a lover of computing archaeology, I fear that when Mr. Gates passes
away, we will have to do with ChatGPT's answer. Oh well.

Aitor

On Sun, 26 Feb 2023 at 15:03, Liam Proven  wrote:

> On Fri, 24 Feb 2023 at 02:52, Ralf Quint  wrote:
>
> > Well, it was OS2.NLM for Netware 3.1x up to 4.10, for 4.11, they named
> > it LONG.NLM.
>
> Faint memory now but sounds right.
>
> > I think starting with Netware 5.0, it was a build-in
> > module, no need to load a special name space anymore.
>
> Could be. I did a training course on NW5 but never deployed it in prod.
>
> > But by that time,
> > the easy use of Netware was gone
>
> IMO that disappeared with 4.
>
>
> > Yeah, that one I remember wasn't very popular, when thinking about that
> > one, actually old "MC Hammer" comes into my head, "can't touch that"...
> 
>
> You needed a Mac client for Netware, and it wasn't popular. I did see
> it a handful of times but the kind of companies who bought Macs and
> Netware were, in my world, mutually exclusive.
>
> > Don't recall anything like this. Also hard to imagine, given the way how
> > they handled permissions. After all, you wouldn't even see sub
> > directories you didn't have the rights to access (one of the stupid
> > things in Windows,).
>
> Even so.
>
> Internally: name begins with $XC%CVBE$%XD%, then don't let users
> $45678 see that...
>
>
> > IIRC, when trying once to do some data recovery on
> > a Netware drive with the help of some folks at Compaq, it was very
> > similar to a FAT filesystem.
>
> Yup.
>
> > Novell never published any technical info
> > about the file system
>
> Yup. It was one nearly half meg file of handcoded assembly, and only a
> few senior programmers understood it. It was the crown jewels and they
> couldn't modernise or adapt it.
>
> Which is why NW5 brought in a whole new FS, but that didn't have the
> performance and brough them down to mainstream nondedicated OS level.
>
>
> > and the guys at Compaq could only give me hints
> > over the phone, they had tech info from Novell but were not allowed to
> > share anything in hard copy from that...
>
> Sounds highly plausible.
>
>
> > I never used anything past 4.11, they tried to compete too much with NT
> > Server at that time already and everything from 5.0 and up was a hot
> mess.
>
> Somewhat but it did get better-integrated with time.
>
> > Might have to check if anyone ever continued to work on MARSNWE, which
> > looked promising for a while until the original author dropped it. Just
> > saw that a couple of years ago, it had been put up on GitHub (GitLab?)
>
> For a

Re: [Freedos-devel] IFS API

2023-02-23 Thread Aitor Santamaría

Hi,

El jue, 23 feb 2023, 0:19, Bret Johnson  escribió:

> > Also I found references on IFSFUNC: in 2Fh (AH=11h), IFSFUNC
> > functions seem to be entangled with the network redirector
> > functions:
> >
> > http://www.ctyme.com/intr/int-2f.htm
> >
> > Apparently, these functions would be made available by IFSFUNC.EXE
> > (curiously not provided by kernel itself).
> >...
> > My conclusion would be that it looks like an alternative
> > functionality update to the network redirector itself (and not
> > something entirely unrelated), that tried to solve some of the
> > previous problems and/or tried to be more abstract and less tied to
> > internal DOS structures, that was implemented only in DOS 4.0,
> >  probably to try and make HPFS available for DOS, but that was later
> > abandoned (due probably to high memory requirements) in favour of
> > maintaining the old redirector).
>
> That's kind of an interesting take, but it's ultimately not what I would
> like to see.  I would like things to be "embedded" as a kernel extension so
> additional drives can simply be "plugged in".  That's how my USBDRIVE
> program currently works.
>
> What I do with USBDRIVE is "inject" the USB drive information into the
> various DOS tables (like the CDS & DPB structures) and the device driver
> chain as needed.  DOS itself already knows how to process FAT12/FAT16 and
> (in some cases) FAT32 partitions/disks.  I leverage that capability so that
> the USB driver doesn't need to handle it.  The USB driver basically just
> gives DOS access to the sectors and DOS processes the data that's in the
> sectors.  As USB disks get plugged and unplugged the various DOS tables get
> updated but DOS already knows how to handle that (DOS can handle removable
> disks with different sizes that all use the same drive letter).
>
> I would like to see a similar setup for additional drive formats (like
> exFAT or HPFS or NTFS or UDF or whatever).  Something where the driver has
> "slots" that different disks can be "plugged" into in real time and the
> software automatically adjusts itself to the disk that's currently
> installed.  I've not studied the network director to know if something like
> that is even possible, but is what' I'd _like_ to see for future
> flexibility and compatibility.
>

Well, I think it's hard to know which were the extra features of IFS over
the already existing network redirector.  This feature (I would include it
as hot plug'n play) could be one, because it's probably IFS which increased
a lot the conventional memory consumption of MS-DOS 4 over 3.x.
However I find it unlikely.  My bet is that IFS included the minimum
necessary to mount HPFS in DOS.

In one of the aforementioned articles, there's a funny comparison between
MS-DOS 4/5 and Windows Vista/7. The former being undeservedly guilty of
horrible memory consumption and the latter seen as a leaner savior.

I can't know the story from my own experience, because I jumped from MS-DOS
3.30 to 6.00 (yeah I lived DOUBLESPACE and not DRIVESPACE).

But being MS-DOS 5.0 published when it was,  after the quarrel with IBM, I
can just speculate that if MS-DOS 5.0 needed more conventional memory, IFS
would have been one of the first things to go.  Which is a pity, because
from those articles one can infer that it tried to make mounting file
systems less reliant on MS-DOS internal structures. A good idea for which
your 16-bit PC has not enough memory :)



> ***
>
> As an aside, I'm wondering if anybody has a "fool-proof" test for FAT32
> capability in the kernel.  In USBDRIVE what I currently do is go through
> all the drive letters and see if any of them responds correctly to INT
> 21.7302h (Get Extended BPB).  This test works if there is at least one
> existing FAT32 drive letter, but will fail if there are no actual FAT32
> partitions even if the kernel supports FAT32.  I don't know of a direct or
> fool-proof way to detect FAT32 support, but maybe somebody else has come up
> with something.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

2023-02-22 Thread Aitor Santamaría

Hi,

Well, thanks to all that contributed to this interesting topic (there are
quite a few interesting mails in the thread).

I could find very little extra information, like this:

https://www.os2museum.com/wp/dos/dos-4-0/

Also I found references on IFSFUNC: in 2Fh (AH=11h), IFSFUNC functions seem
to be entangled with the network redirector functions:

http://www.ctyme.com/intr/int-2f.htm

Apparently, these functions would be made available by IFSFUNC.EXE
(curiously not provided by kernel itself).
So I suppose the current only way to know more would be to acquire a MS-DOS
(or IBM-DOS) 4.0, disassemble this file.

My conclusion would be that it looks like an alternative functionality
update to the network redirector itself (and not something entirely
unrelated), that tried to solve some of the previous problems and/or tried
to be more abstract and less tied to internal DOS structures, that was
implemented only in DOS 4.0, probably to try and make HPFS available for
DOS, but that was later abandoned (due probably to high memory
requirements) in favour of maintaining the old redirector).

Aitor



On Wed, 22 Feb 2023 at 19:25, C. Masloch  wrote:

> On at 2023-02-22 01:05 +, Yll Buzoku wrote:
> > Hi Aitor,
> >
> > Preface:
> >
> > The following holds true for PC-DOS 3.3, though I have no reason to
> > suspect anything I say holds any different for any DOS version from 3.1
> > onwards.
>
> The LoL, SDA, CDS, and SFT layouts differ somewhat between MS-DOS
> versions 3.x, 4.x, and 5.x I believe. And a few calls (like the 2F.11
> service to implement 21.6C Extended Open/Create) are version-specific.
>
> > My understanding of what is expected of the redirector
> > interface is due to having disassembled the DOS 3.3 kernel to understand
> > how it works and may not be 100% accurate. Also, DOS 3.0 has some unique
> > quirks but as far as the following is concerned, I suspect it works more
> > or less the same as later DOS versions. DOS versions before that had no
> > redirector interface.
> >
> > DOS has two 128-byte buffers in the Swappable Data Area. Initially, on a
> > file-based request, such as AH=3Dh (OPEN), DOS will parse the passed
> > filename into one of these buffers and place a pointer to it in another
> > SDA variable. This parsing routine expects 8.3 names at all stages in
> > the pathname except at the very beginning where if the pathname begins
> > with \\ DOS understands this as referencing a path on a network machine
> > and allows a valid MS-NET machine name as the first component of the
> path.
> >
> > FCB functions work like this too, but the way DOS handles them is a bit
> > more convoluted, though you can imagine FCB handling by DOS as
> > converting the FCB request to a normal file request, then proceeding as
> > normal and at the end synchronising the FCB fields before returning
> > control back to the application. Of course, you can only act upon files
> > on drives with drive letters when using FCBs.
> >
> > If the parsing routine ascertains that the request is to be run on a
> > network drive, either due to a \\ pathname specification or due to a
> > drive letter being specified that refers to a registered, mounted
> > network drive (see CDS Flags to see how this is determined), DOS will,
> > at the point of the file operation, redirect the call to the relevant
> > Int 2Fh AH=11xxh Network Redirector function (RBIL has these more or
> > less completely listed) for the DOS call made. For example, for OPEN
> > (AH=3Dh), DOS will call Int 2Fh AX=1116h. Note that most calls don't
> > work with a machine name (as most calls require a CDS and those only
> > exist for drives). For example, OPEN will fail if you pass a filename
> > beginning with a "\\".  On the other hand, CREATE (AH=3Ch) works for
> > both cases.
> >
> > Once control is transferred to the network redirector, it is then
> > expected to extract the pointer to the parsed filename from the SDA and
> > use it to do... whatever. Of course, it doesn't _have_ to that as the
> > PSP of the task which made the request is directly accessible to the
> > redirector via the SDA (or via Int 21h AH=62h, a re-entrant DOS
> > function). Crucially, the PSP has a copy of the value of SS:SP of the
> > program which made the request, and it is set by DOS to point to a copy
> > of the callers' registers as they were on entering DOS.
>
> I believe there exists an SDA field (or two) pointing to the user stack
> frame created by the DOS call. But yes, this is also accessible in the
> PSP, though usually the only reader of *that* pointer is DOS process
> termination (to regain the parent process's stack).
>
> > That includes
> > the pointer to the original "unparsed" LFN filename in DS:DX. Therefore,
> > a redirector could access the LFN passed by an application by taking the
> > pointer to the path in the method described above, thus allowing the
> > redirector to implement LFN's however it so chooses. This is a
> > hypothetical way for a network

Re: [Freedos-devel] IFS API

2023-02-21 Thread Aitor Santamaría

Thanks!!

Just a 5-min check so I may be wrong, but it seems to hook int13h and issue
some Iomega ZIP HPFS driver SCSI calls to do the work.
Which is just another way to accede other filesystems. :)

Aitor


On Tue, 21 Feb 2023 at 03:27, Rugxulo  wrote:

> Hi,
>
> On Sun, Feb 19, 2023 at 7:39 PM Aitor Santamaría 
> wrote:
> >
> > Does anyone know if the IFS (Installable File System) API is documented
> anywhere?
>
> I have no idea if this link will help you, but I'm mentioning it "just
> in case" (because it sounds useful and impressive).
>
> * https://ecsoft2.org/ihpfs
>
> Basically, it's a read-only HPFS driver for DOS (last updated by Veit
> Kannegieser).
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

2023-02-21 Thread Aitor Santamaría

Hi,

On Tue, 21 Feb 2023 at 01:41, Ralf Quint  wrote:

> On 2/20/2023 1:52 PM, Aitor Santamaría wrote:
> > Hello Eric,
> >
> > More than useable, it was just a question of historical curiosity.
> >
> > In a very long time ago posted thread  (I haven't tested myself) it
> > was suggested that the redirector API does not work well with LFNs. I
> > am not suggesting that the unmaintained DOS IFS would do, but I was
> > curious to know how do these two different approaches to third party
> > filesystems (redirector and IFS) compare to each other, and how they
> > both deal with: LFNs, case sensitivity, unicode names, big files, and
> > a long etc.
> >
> That is not very surprising, as the DOS network redirector was devised
> well before long filenames became a thing with Windows 95B. And I do


Yeah well, that doesn't sound too sensible to me is that you implement LFN
only for int 21h and you don't bother to adapt the redirector, which is
your designed escape way for other filesystems?

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

Re: [Freedos-devel] IFS API

2023-02-21 Thread Aitor Santamaría

Thanks Ralf for the file, it is very interesting.

I am not fully convinced that NOTHING from the IFS was ever developed in
MS-DOS 4.X and later taken back in 5.0+.

The network redirector appeared earlier, and I suppose that with IFS, MS
tried to resolve some absent functionality in the network redirector.

Aitor

On Tue, 21 Feb 2023 at 01:18, Ralf Quint  wrote:

> On 2/20/2023 11:58 AM, Aitor Santamaría wrote:
>
> Thanks, Ralf!!
>
> So I thought, but I have read a couple of references (such as the
> following in Wikipedia, but not the only one) by which the IFS was present
> in MS-DOS 4.X, of course as well as in OS/2 and Windows:
>
> Installable File System - Wikipedia
> <https://en.wikipedia.org/wiki/Installable_File_System>
>
> Apparently, there was some support for it that was probably removed for
> MS-DOS 5.0 and later. Part of the mystery (to me) of MS-DOS 4.X! :)
>
> In RBIL, the only reference I've found is to IFSHLP.SYS, which was a
> Windows mean to guess what has been installed before getting into protected
> mode, so I am not sure is if this has to be with the IFS that was planned
> and implemented in MS-DOS 4.0.
>
> Windows and OS/2 are totally different ball games. In DOS, as long as I
> can remember, only the network redirector existed. That MSCDEX.TXT that I
> mentioned I think tries to explain that as well...
>
> Don't recall when MSCDEX first showed up, but I think it was after the
> networking redirector stuff (for both Novell and LanManager) in MS-DOS 3.0.
>
>
> Ralf
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

2023-02-20 Thread Aitor Santamaría

Hello Eric,

More than useable, it was just a question of historical curiosity.

In a very long time ago posted thread  (I haven't tested myself) it was
suggested that the redirector API does not work well with LFNs. I am not
suggesting that the unmaintained DOS IFS would do, but I was curious to
know how do these two different approaches to third party filesystems
(redirector and IFS) compare to each other, and how they both deal with:
LFNs, case sensitivity, unicode names, big files, and a long etc.

Aitor

On Mon, 20 Feb 2023 at 22:04, Eric Auer  wrote:

>
> Hi! As we have various drivers which use the network redirector API,
> CD/DVD redirector API or both, including drivers which use those for
> different purposes, which advantage do we expect from using a special
> IFS API which is both "more on topic" and "less existing", as in only
> very specific DOS versions may have supported it? My impression was
> that things like vmsmount and etherdfs work fine without that API :-)
>
> Also note that the low-level format is not visible through IFS, so it
> does not matter whether you use FAT32, FAT16 or NTFS. However, it may
> matter whether you want long file names or files > 2 GB. For those,
> I hope that the usual Win9x DOS 7.x int 21 calls have counterparts in
> the network and CD redirector API space of the same DOS generations.
>
> Regards, Eric
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

2023-02-20 Thread Aitor Santamaría

Many thanks!
Interesting link.

On Mon, 20 Feb 2023 at 21:52, Mercury Thirteen via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> If it was in fact removed from the "official" MS-DOS, and one wanted to
> (re)implement it anyway, perhaps browsing the code of the open-source
> recreation of OS/2 would help? It has a FAT32 driver which is compatible
> with the OS/2 IFS and, as I recall, OS/2 was more of a direct successor to
> MS-DOS than Windows ever was, so perhaps its code would be more helpful to
> a DOS dev as opposed to the Windows versions.
>
> Not sure, I haven't dug too deeply into that myself, but hope it possibly
> helps.
>
> https://www.arcanoae.com/wiki/fat32/
>
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> --- Original Message ---
> On Monday, February 20th, 2023 at 2:58 PM, Aitor Santamaría <
> aitor...@gmail.com> wrote:
>
> Thanks, Ralf!!
>
> So I thought, but I have read a couple of references (such as the
> following in Wikipedia, but not the only one) by which the IFS was present
> in MS-DOS 4.X, of course as well as in OS/2 and Windows:
>
> Installable File System - Wikipedia
> <https://en.wikipedia.org/wiki/Installable_File_System>
>
> Apparently, there was some support for it that was probably removed for
> MS-DOS 5.0 and later. Part of the mystery (to me) of MS-DOS 4.X! :)
>
> In RBIL, the only reference I've found is to IFSHLP.SYS, which was a
> Windows mean to guess what has been installed before getting into protected
> mode, so I am not sure is if this has to be with the IFS that was planned
> and implemented in MS-DOS 4.0.
>
> Aitor
>
>
>
>
>
>
>
>
>
>
>
> On Mon, 20 Feb 2023 at 18:27, Ralf Quint  wrote:
>
>> On 2/19/2023 5:38 PM, Aitor Santamaría wrote:
>> > Hello,
>> >
>> > Does anyone know if the IFS (Installable File System) API is
>> > documented anywhere?
>> >
>> Just checked in my archive of docs, and there is a MSCDEX.TXT, which
>> describes the interface for the CD-ROM "network redirector".
>>
>> It can apparently be found online at
>> https://cybermax.tripod.com/mscdex.txt
>>
>>
>> Ralf
>>
>>
>>
>>
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

2023-02-20 Thread Aitor Santamaría

Thanks, Ralf!!

So I thought, but I have read a couple of references (such as the following
in Wikipedia, but not the only one) by which the IFS was present in MS-DOS
4.X, of course as well as in OS/2 and Windows:

Installable File System - Wikipedia
<https://en.wikipedia.org/wiki/Installable_File_System>

Apparently, there was some support for it that was probably removed for
MS-DOS 5.0 and later. Part of the mystery (to me) of MS-DOS 4.X! :)

In RBIL, the only reference I've found is to IFSHLP.SYS, which was a
Windows mean to guess what has been installed before getting into protected
mode, so I am not sure is if this has to be with the IFS that was planned
and implemented in MS-DOS 4.0.

Aitor

On Mon, 20 Feb 2023 at 18:27, Ralf Quint  wrote:

> On 2/19/2023 5:38 PM, Aitor Santamaría wrote:
> > Hello,
> >
> > Does anyone know if the IFS (Installable File System) API is
> > documented anywhere?
> >
> Just checked in my archive of docs, and there is a MSCDEX.TXT, which
> describes the interface for the CD-ROM "network redirector".
>
> It can apparently be found online at
> https://cybermax.tripod.com/mscdex.txt
>
>
> Ralf
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] IFS API

2023-02-19 Thread Aitor Santamaría

Hello,

Does anyone know if the IFS (Installable File System) API is documented
anywhere?

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

Re: [Freedos-devel] keyb kl

2023-02-07 Thread Aitor Santamaría

Hello,

Could you post the source KEY file?
My educated guess is that a command (key combination) to change current
submapping is being used. This is pretty useful, but if the two submappings
are written for different codepages, it may not work as expected.

Aitor





On Tue, 7 Feb 2023 at 14:07, wilhelm.spiegl 
wrote:

> Hi Aitor,
>
> thanks for this information. It helped and I could create the .kl files
> with the key files delivered with kpdos31s.zip (not kpdos31x.zip). Some
> "ltxx.key" files gave a message:
>
> Warning at line xxx: Change of submapping changes the codepage
> of KEYB and leave KEYB in an inconsistent state (sm: 12->10) but worked,
> just for information.
>
> Is there any reason why it maybe not wishful to use these .kl files with
> keyb although they are mentioned in keyb? Should they be added at the
> kpdos-3.1 file?
>
> Willi
>
>
>
> Von meinem/meiner Galaxy gesendet
>
>
>  Ursprüngliche Nachricht 
> Von: Aitor Santamaría 
> Datum: 06.02.23 22:49 (GMT+01:00)
> An: "Technical discussion and questions for FreeDOS developers." <
> freedos-devel@lists.sourceforge.net>
> Betreff: Re: [Freedos-devel] keyb kl
>
> Hello Wilhelm,
>
>
> On Mon, 6 Feb 2023 at 22:15, wilhelm.spiegl 
> wrote:
>
>> Hi, Aitor,
>> I am not sure if I understand you correct. kc 200 is available here:
>>
>>
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/fdkeyb-2.0/
>> kc200
>>
>> I tried kc with the key files from xkeyb that are delivered with the
>> fdt2302.iso.
>>
>
> but executing "kc gr.key" or another one language leads to the reported
>> message so that I got no kl file.
>>
>> The KEY files from xkeyb are a completely different story. Try the files
> at KPDOS, which are KEY files in the KEY language format that FD-KEYB
> understands.
>
>
>
>> I do not need the kl files for myself, maybe some for testing, but I
>> think they should be delivered with keyb.exe It would be nice if you could
>> send them to Jerome Shidel.
>>
> I suppose there are no KL files, because from the KEY files you compile to
> KL, and then they are packed. A KL file is like a .O file, not very useful
> in itself.
> You either get the KEY files (like .C) or the libraries (like .EXE), but
> not the .KL (like the .O).
>
> But you can easily build yourself the KL files from the KEY files written
> in the FD-KEYB language (or at least they should compile, I haven't tried
> that for a long time). Henrique Peron is the author of the KEY/KL files, a
> very impressive work IMHO.
>
> Aitor
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] keyb kl

2023-02-06 Thread Aitor Santamaría

Hello Wilhelm,


On Mon, 6 Feb 2023 at 22:15, wilhelm.spiegl 
wrote:

> Hi, Aitor,
> I am not sure if I understand you correct. kc 200 is available here:
>
>
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/fdkeyb-2.0/
> kc200
>
> I tried kc with the key files from xkeyb that are delivered with the
> fdt2302.iso.
>

but executing "kc gr.key" or another one language leads to the reported
> message so that I got no kl file.
>
> The KEY files from xkeyb are a completely different story. Try the files
at KPDOS, which are KEY files in the KEY language format that FD-KEYB
understands.



> I do not need the kl files for myself, maybe some for testing, but I think
> they should be delivered with keyb.exe It would be nice if you could send
> them to Jerome Shidel.
>
I suppose there are no KL files, because from the KEY files you compile to
KL, and then they are packed. A KL file is like a .O file, not very useful
in itself.
You either get the KEY files (like .C) or the libraries (like .EXE), but
not the .KL (like the .O).

But you can easily build yourself the KL files from the KEY files written
in the FD-KEYB language (or at least they should compile, I haven't tried
that for a long time). Henrique Peron is the author of the KEY/KL files, a
very impressive work IMHO.

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

Re: [Freedos-devel] keyb kl

2023-02-06 Thread Aitor Santamaría

Hello Wilhelm!

The mechanic is:  KC is the tool to transform a KEY into KL. And then, KLIB
packs the KL files into a single library (like KEYBOARD.SYS).
My suggestion is that you start with an existing KEY file, rather than
trying to build from scratch:

Index of /pub/micro/pc-stuff/freedos/files/dos/keyb/kblayout/kpdos-3.1
(ibiblio.org)


Use the sources (in KEY language).

For the language itself: it is true that the compiler/library does NOT
exist in ibiblio anymore. I have commented on an already open bug about it.
(bug 181).
I have tried to send some documentation but it is too big for
lists.sourceforge.
I have the KC/KLIB package if needed, but Gmail will not let me send it
through email.

AItor

On Mon, 6 Feb 2023 at 15:00,  wrote:

> Hi,
>
> J just try to change my email accounts to mnet as mail.com is no longer
> usable (when clicking on a mail they start with a video etc.).
>
> My problem is once again the FD help 1.1.0 (under construction).
>
> The documentation of keyb says that it is possible to work with
> keyboard.sys and keybrd2/3/4.sys (depending on keyboard layout).
>
> This works fine. But there is also an information that it should work with
> ".kl" files. Till now I found none of these .kl files at ibiblio or github.
>
> At Ibiblio I found a tool kc200 (hidden in a wrong subfolder? - it is not
> at gitlab) which should be able to convert key files to kl files, but the
> kc command gives an error message 16: section [submappings] is mandatory
> for linking. This is an interesting sentence for mouse pusher user like me
> for a tool that says that you simply have to enter kc xy.key.
>
> So, is there a way to obtain this kl files - or should I simply remove
> them from the help file?
>
> Thx for checking and maybe adding .kl files to keyb if necessary.
>
>
> Willi
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

2023-01-30 Thread Aitor Santamaría

Hello,

On Sun, 29 Jan 2023 at 22:59, Jim Hall  wrote:

> I think Microsoft would have had to find a way around the obvious
> limitations in DOS, inherent in an operating system from 1981. With
> more powerful CPUs, more memory, and networking, you need a more
> powerful operating system. Let's call it "newDOS" and it is otherwise
> a "DOS" operating system: command line in text mode. New programs use
> a "newDOS" API, like any regular operating system. This "newDOS" also
> needs to provide multitasking, and a better memory model (flat memory,
> large address space, etc). "newDOS" also needs to provide a built-in
> network stack, so you don't have to keep loading drivers and
> configuring each application separately to talk to the network.
>

In my opinion, they actually did this. Pick Windows95, rename COMMAND.COM
to KRNL386.EXE (i.e. Windows) to avoid the GUI load into VM0 and there you
go a preemptive multitasking DOS with 32-bit device driver support and
virtual memory. No networking but I suppose someone can write a VNETD.VXD
device driver and you're done.

The magic is made by VMM32.VXD (formerly WIN386.EXE, formerly DOS386.EXE),
a highly evolved version of EMM386.EXE (hence the discussion in the other
thread whether EMM386 is a VMM or not: it is, but it is still a very
rudimentary one, as Tom pointed out). That's why in other threads I defend
that VMM32/VXDs are an evolved version of DOS and not Windows (unlike
NTOSKRNL, which is pure Windows), and that underneath the Windows 9X skin,
MS-DOS (a 32-bit version of MS-DOS) is beating.

Back to the supposed textmode version, if they had implemented the
Ctrl+Alt+Fn way of switching sessions, as in some earlier Linux
distributions, you could have had what you say, have Lotus 1-2-3 run in
VM1, WordPerfect in VM2...  (Ctrl+Alt+F1 or Ctrl+Alt+F2 to switch from one
to the other).

It is just that the popularity of GUIs made them prefer the Win32 API to
any kind of DOS extension API. Even the concept of DLL can survive in such
a 32-bit pure version of DOS without implying Windows. And if you are
mainly designed to run Win32 applications, use NT kernel instead of DOS.

Until Windows98 things seemed to go well: FAT32 support, LFN support, LBA
support. Then WindowsME came to commit suicide and killed this 32-bit line
of MS-DOS.

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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware

2023-01-25 Thread Aitor Santamaría

Thanks, these work!

Aitor

On Wed, 25 Jan 2023 at 21:46, Robert Riebisch  wrote:

> Hi Aitor,
>
> > Both links give me a 404, maybe a problem with pasting?
>
> https://dosbox-x.com/wiki/Guide%3ADOS-Installation-in-DOSBox%E2%80%90X
> https://dosbox-x.com/wiki/Guide%3AManaging-image-files-in-DOSBox%E2%80%90X
>
> Cheers,
> Robert
> --
> BTTR Software   https://www.bttr-software.de/
> DOS ain't dead  https://www.bttr-software.de/forum/
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS install ebook (Spanish)

2023-01-25 Thread Aitor Santamaría

Hello,

Another curiosity I've found on the web:

FREEDOS 1.0. - Curso de Técnico de Redes y Sistemas 2011 (yumpu.com)


This site features an eBook, 24 pages (in Spanish) explaining how to
install FreeDOS over a VMWare virtual machine.

It's cool to find out how FreeDOS arouses interest for such kind of
projects.

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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware

2023-01-25 Thread Aitor Santamaría

Hello Ben,

Both links give me a 404, maybe a problem with pasting?

Aitor


On Wed, 25 Jan 2023 at 18:21, Ben Collver  wrote:

> On Tue, 24 Jan 2023, Bret Johnson wrote:
>
>
>
> > For purposes we're discussing here, I don't think DOSBox (or any of its
>
> > forks, including vDOS) is a viable solution.
>
> >
>
> > DOSBox really isn't DOS.  It's an environment designed to run certain
>
> > DOS applications.  A lot of stuff is missing in DOSBox that's needed to
>
> > make it a "real enough" DOS to be used for development and testing.
>
> > E.g., a lot of the internal structures that some DOS "extenders" need to
>
> > look at (like certain TSRs and Device Drivers) simply don't exist on
>
> > DOSBox.
>
> You can install FreeDOS in DOSBox.  See the links below for more details.
> In my experience qemu and VirtualBox are not really geared toward
> supporting DOS and they have annoying BIOS bugs that are not present in
> DOSBox.  So while FreeDOS runs more quickly in qemu and VirtualBox, it runs
> more accurately in DOSBox-X.
>
>
> https://dosbox-x.com/wiki/Guide%253ADOS-Installation-in-DOSBox%25E2%2580%2590X
>
>
> https://dosbox-x.com/wiki/Guide%253AManaging-image-files-in-DOSBox%25E2%2580%2590X
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS / Jim on TheRegister

2023-01-23 Thread Aitor Santamaría

Hello,

Founder of FreeDOS recounts the story so far, and the future • The Register


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

[Freedos-devel] FreeDOS mentioned on xataka

2023-01-18 Thread Aitor Santamaría

Hello,

FreeDOS is mentioned in this popular computer blogging in Spanish (xataka).

Cómo instalar Windows 11 en un ordenador con FreeDOS (xataka.com)


The blog entry is on "how to install Windows 11 in a computer having
FreeDOS".
Not my favourite blog entry: it does mention that FreeDOS can be used to
play old games, but it is also mentioned as a mean for manufacturers to
overcome paying for WIndows licenses, but "there is no interface that you
can use with a mouse, you have to operate it fully on commands",  but less
accurately (in my opinion) is:
* FreeDOS is heir to MS-DOS
* One of its functions is to allow you to install other operating systems.

I suppose this is a view largely shared today with those that are not too
familiar of what DOS is and how the PCs evolved.

Nothing new I guess, but I suppose it's worth mentioning here.

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

Re: [Freedos-devel] print / printq / spool / graphics

2023-01-08 Thread Aitor Santamaría

Hello,

On Wed, 4 Jan 2023 at 01:52, Jim Hall  wrote:

> >> a) printer.htm (printer.sys) (in htmlhelp):
> >>
> >> According to help 1.0.5 this version was made by Aitor
> >> SANTAMARIA MERINO with copyright 2003. I overtook it from
> >> Rob Plat "as is".  I did not find the files at Ibiblio.
> >> Question: Is it still in use - and where can I find it? Or
> >> can I forget it?
>

PRINTER.SYS (or PRINTER.COM) would be a totally different project from
printer queues, etc. that is being discussed here.

PRINTER.SYS would be to PRN (LPT1) what DISPLAY.SYS is to CON: it would
provide the PRN device with IOCTL functions, that is, codepage management
functions, by means of using printer-specific commands sent to the printer,
and eventually, even sending full codepage information to a printer.

This is useful for when a codepage change command is issued:

CHCP 850

Kernek would issue the ioctl calls to all devices and no device is left
inconsistent (unlike what happens with the MODE CON CP SELECT= call).

Making this requires two things:

(1) Printer model specific commands for codepage management inside
PRINTER.SYS/COM (the same way that DISPLAY has CGA, EGA and VGA specific
functions):
DISPLAY CON=(EGA,)
would be
PRINTER PRN=(my_printer,...)

(2) codepage specific data files, that contain bulk codepage information to
be sent to the printer by means of MODE:
MODE CON CODEPAGE PREPARE=((850) EGA.CPX)
would be
MODE PRN CODEPAGE PREPARE=((850)  codepage_information_file)

Regrettably, I don't have any of the codepage information files, or their
format so that MODE can bulk send them to PRINTER.SYS. And second, very
long long time ago I was sent SOME information about PCL printers, but this
project is not very appealing to me, as I assume there are not many FreeDOS
users that would find this useful.

So although DISPLAY sources could be slightly adapted to produce a
PRINTER.SYS/COM, there is no PRINTER that I know of.

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

[Freedos-devel] FD-KEYB issue tracking

2022-11-16 Thread 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-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Toggling directories

2022-11-09 Thread Aitor Santamaría

Agreed.

To me this is a bug. Not a major one, but a bug.

Aitor


On Wed, 9 Nov 2022 at 16:28, Jerome Shidel  wrote:

> Hi all,
>
> There is a minor compatibility difference with the FreeCOM DIR command.
>
> Most of the option switches work like toggles. For example:
>
> dir /w - shows a wide listing
> dir /w /w  - shows a normal listing
> dir /w /w /w  - shows a wide listing
>
> This deviates from MS-DOS
>
> dir /w - shows a wide listing
> dir /w /w - shows a wide listing
>
> To toggle it back off MS-DOS requires the /-w switch and works fine with
> the FreeCOM DIR.
>
> When used through an alias like “set alias ls=dir /w” then executing “ls
> /w” it produce results different from what is expected.
>
> Not all options perform toggling. For example:
>
> dir /p - pauses per page
> dir /p /p  - pauses per page
>
> I don’t think the toggling is very important. But, it does deviant from
> MS-DOS.
> I do think that consistency across the options is important.
>
> Any thoughts?
>
> :-)
>
> Jerome
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Problem with procedural types in 16-bit DOS FreePascal

2022-11-08 Thread Aitor Santamaría

Hello Ralf,

On Tue, 8 Nov 2022 at 02:16, Ralf Quint  wrote:

> On 11/7/2022 4:56 PM, Aitor Santamaría wrote:
>
>
> After all, if you declare a procedure to be far is because you want it to
> be called far, right?
>
> I have not tried anything like this with 16bit FPC, but in BP7 (and
> probably before that, but that's +30 years ago  ), procedural parameters
> have always been a far call. As Jerome mentioned, interface'd
> procedures/functions are far by default, as each unit has it's own code
> segment. And if you are using function/procedures within the same unit, you
> have to declare them as FAR. The FAR declaration is only a newer version of
> {$F+} compiler directive, which definitely was needed in TP3, not sure with
> which version of TP/BP this was introduced.
>

KEYB lies in a single PAS file, no units or any fancy stuff.
I am considering to modularise a bit in the future to make it more
readable, via $I, but not in units.

As for FPC, do you explicitly use it in {$MODE TP} mode to be compatible
> with TP/BP? (https://www.freepascal.org/docs-html/user/userse33.html) I
> am not sure right now (don't have an FPC with 16bit option installed
> anywhere here right now) how 16bit FPC is compatible with all those
> compiler options, I just recall that there was mentioned that a lot of the
> newer fluff that had been added to FPC in recent years (interface,
> generics, etc) won't work because of the memory/CPU restrictions imposed...
>
Yeah, as said in the other mails, I have tried using  -MTP when compiling,
which I assume to be equivalent to {$MODE TP}.
The problem mutates in a different casting problem, but is still there.
No fancy new stuff being used in KEYB, it's mostly assembler for the
resident part, and plain Pascal for parsing of the commandline and such.

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

Re: [Freedos-devel] Problem with procedural types in 16-bit DOS FreePascal

2022-11-07 Thread Aitor Santamaría

Hello!

I simplified my email, but this is how it is actually being done :(

Aitor


On Mon, 7 Nov 2022 at 14:38, stefano cirilli  wrote:

> Hi, try to define the variable as a Type:
>
> I googled this:
> Type TOneArg = Procedure (Var X : integer); on
> https://www.freepascal.org/docs-html/ref/refse17.html
> On 07/11/22 01:18, Aitor Santamaría wrote:
>
> Hello,
>
> I am trying to recompile FD-KEYB using 16-bit DOS FreePascal, in order to
> see if I can produce a FPC version and thus avoid using TPC for compiling.
>
> I am not being very lucky with compiling itself, and I haven't raised too
> much attention in the FPC lists, either because it is difficult, or most
> probably, compiling for an old 16-bit OS does not raise too much interest.
>
> So I am trying this list here, in case some of you have ever mangled
> 16-bit FPC and know the answer.
>
> The biggest problem I am having is with the procedural type variables.
> Whereas TPC would swallow this:
>
> VAR
>v: procedure;
>
> procedure P;
> begin
> ...
> end;
>
> v := P;
>
> FPC does not like it, as it is trying to assign the RESULT of P (untyped)
> to v.
>
> KEYB.PAS(2960,21) Error: Incompatible types: got "untyped" expected
> ""
>
> The documentation tells me to use
>
> v := @P;
>
> but it does not work, it gives:
>
> KEYB.PAS(2960,21) Error: Illegal type conversion: " procedure;far;Pascal>" to ""
>
> which puzzles me, because to my  mind, they are the same thing.
>
>
> Using -MTP compiler option does not help, I get lots of new errors, unless
> I avoid it by
>
> TYPE
> SimpleProc = procedure; far; { parameter-less callable
> function }
>
> (which is NOT standard TP language at all), but would in turn give me:
>
> KEYB.PAS(2960,21) Error: Illegal type conversion: " procedure;far;Pascal>" to "NearCsPointer"
>
> You can read the full thread here:
> Far pointer versus Pointer in 16-bit DOS (freepascal.org)
> <https://forum.lazarus.freepascal.org/index.php/topic,60973.0.html>
>
>
> Any hints on how to circumvent this problem?
>
> Thanks in advance,
> Aitor
>
>
>
>
> ___
> Freedos-devel mailing 
> listFreedos-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freedos-devel
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Problem with procedural types in 16-bit DOS FreePascal

2022-11-07 Thread Aitor Santamaría

Hello,

On Mon, 7 Nov 2022 at 10:12, Rugxulo  wrote:

> Hi,
>
> On Sun, Nov 6, 2022 at 9:08 PM Jerome Shidel  wrote:
> >
> > Make sure your compiling to the correct memory model. (I think huge, but
> you’ll need to double check that)
>
> Default is Small, e.g. "-WmSmall". I assume "-WmCompact" would work
> better for you?
>
It does. It is the mode I am using.


> > You may need to ensure the actual procedure is declared with far.
> >
> > Procedure Test; far;
> > Begin
> > End;
>
> In old freeware TP 5.5, that would be {$F+} at the top and {$F-} at
> the bottom of the procedure. (I believe all procedures within the same
> unit / file are near while external procedures are far by default.)
>
I have tried with ALL the program with {$F+}, and no luck, same error.

Besides, the procedures I am assigning are all FAR. What would be the
difference between these two?

{$F+}
Procedure Test;
Begin
End;
{$F-}

Procedure Test; far;
Begin
End;

After all, if you declare a procedure to be far is because you want it to
be called far, right?


> > Also, you may need assign the address to a plain pointer and typecast
> the call.
>
> Is that needed??
>
Does not help anyway.


> > Also, there are also compiler directives for FPC regarding compatibility.
>
> Default dialect is "fpc", which is less strict than {$mode tp}, e.g.
> it does change function pointer syntax a bit, but it also gives you
> structured return types and function overloading.
>
> {$asmmode intel} is only default for {$mode tp} as well (but you can
> manually enable it, too).
>
Well, instead of a directive, I tried to compile with and without TP mode
(-MTP), and it did not fix it (in the original mail you can see how the
error changed, but still does not compile).
They are both still too strict. I would really love it if two variables of
the same size could be typecasted without any restriction (the programmer
knows).


> Don't forget you can also declare inline functions! (Like real
> inlining, not just inline machine code.)
>
I didn't understand this  ¿?

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

Re: [Freedos-devel] Problem with procedural types in 16-bit DOS FreePascal

2022-11-07 Thread Aitor Santamaría

Hello Jerome,


On Mon, 7 Nov 2022 at 04:08, Jerome Shidel  wrote:

> Make sure your compiling to the correct memory model. (I think huge, but
> you’ll need to double check that)
>
Compact is the one that gives me less problems (it's also the one that got
most recommendations :) ).


> You may need to ensure the actual procedure is declared with far.
>
Yeah, all of them are far.

Procedure Test; far;
> Begin
> End;
>
> Also, you may need assign the address to a plain pointer and typecast the
> call.
>
> Type
>   MyProc = procedure;
>
> Var
>   P : pointer;
>
> Begin
> P := @Test;
> MyProc(P^);
> End.
>

I tried that last bit (MyProc(P^)), but no luck:
KEYB.PAS(3382,28) Error: Illegal qualifier
KEYB.PAS(3382,29) Error: Illegal expression


> Also, there are also compiler directives for FPC regarding compatibility.

-MTP did not work :(
It changed the error for another.

Thanks anyway... :(

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

[Freedos-devel] Problem with procedural types in 16-bit DOS FreePascal

2022-11-06 Thread Aitor Santamaría

Hello,

I am trying to recompile FD-KEYB using 16-bit DOS FreePascal, in order to
see if I can produce a FPC version and thus avoid using TPC for compiling.

I am not being very lucky with compiling itself, and I haven't raised too
much attention in the FPC lists, either because it is difficult, or most
probably, compiling for an old 16-bit OS does not raise too much interest.

So I am trying this list here, in case some of you have ever mangled 16-bit
FPC and know the answer.

The biggest problem I am having is with the procedural type variables.
Whereas TPC would swallow this:

VAR
   v: procedure;

procedure P;
begin
...
end;

v := P;

FPC does not like it, as it is trying to assign the RESULT of P (untyped)
to v.

KEYB.PAS(2960,21) Error: Incompatible types: got "untyped" expected
""

The documentation tells me to use

v := @P;

but it does not work, it gives:

KEYB.PAS(2960,21) Error: Illegal type conversion: "" to ""

which puzzles me, because to my  mind, they are the same thing.


Using -MTP compiler option does not help, I get lots of new errors, unless
I avoid it by

TYPE
SimpleProc = procedure; far; { parameter-less callable
function }

(which is NOT standard TP language at all), but would in turn give me:

KEYB.PAS(2960,21) Error: Illegal type conversion: "" to "NearCsPointer"

You can read the full thread here:
Far pointer versus Pointer in 16-bit DOS (freepascal.org)



Any hints on how to circumvent this problem?

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

Re: [Freedos-devel] FreeDOS Interim Build T2210

2022-10-01 Thread Aitor Santamaría

Hello,

On Sat, 1 Oct 2022 at 16:49, Jerome Shidel  wrote:

> As I see it, this leaves us with 3 choices:
>
> 1) Drop nearly 300mb of packages from the CD.
> 2) Do nothing and call it a DVD
> 3) Move all development related packages onto their own disc. Have DevelCD
> and seperate BonusCD.
>

>From the three, in my opinion (3) is the more sensible: make a difference
between user-oriented distribution and developer-oriented distribution (so
don't call it BonusCD but "Developer's edition" or something similar.

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

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

2022-08-14 Thread 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-devel@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-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS and Translations

2022-08-14 Thread Aitor Santamaría

Hi,

On Mon, 24 May 2021 at 21:49, Jerome Shidel  wrote:

> Hi Willy,
>
> > On May 24, 2021, at 3:22 PM, Wilhelm Spiegl 
> wrote:
> >
> > question about nls, do they all have to be written in the correct
> codepage used by the language / country set in freedos?
> > some time ago i checked and noticed that this is not the fact. they are
> made in different ways, some with windows, some with linux, the result was
> that special
> > characters like äöü or french or spanish accents maybe shown not correct.
> >
> > so first of all, what is the correct handling?
>
> At present, the translations on the Github repository are in a
> “ready-to-use” state that the appropriate program can read without issue.
> They should be in the proper DOS codepage and have the correct line endings
> supported by the program. Occasionally, translators supply versions in
> UTF-8. Generally, the translators seem to prefer working in UTF-8. I assume
> it to prevent character mangling. Anyhow when they supply those, they are
> just kept along side the proper DOS codepage versions. A program that
> imports the latest translations simply ignores all files ending in UTF-8.
>
> Eventually, I’ll provide a better system to convert to/from UTF-8. I know
> there are tools for the conversion. But for now, I rely on the translator
> to provide the final Codepage version.

In addition, I guess a good way to follow is that translated files are
encoded with a codepage suitable for the language, that may be the codepage
that the Installer chooses for that language.
Is this information somewhere available? if it doesn't, I think a simple
table LANG > CODEPAGE would be very useful, so that problems with encoding
can be tracked and users can provide feedback (and make the installation be
faithful to this table). I assume for example that for Spanish, that could
be 858 (Western European + Euro sign) to avoid the problems mentioned by
Wilhelm. This is a simple case (I guess that 858 is suitable for America),
but probably there are cases where language is not enough, and
language+country is required, if the same language is spoken in countries
with quite a different codepage needs.

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

Re: [Freedos-devel] GitLab - problem with codepages

2022-08-03 Thread Aitor Santamaría

Thanks to both.

Yeah as I saw the problem at commit, I think the problem is within the
editor.
I've just been trying VSC for the first time but didn't expect to come
across this :(

I'll figure out, thanks anyway.

Aitor




On Wed, 3 Aug 2022 at 01:30, Jerome Shidel  wrote:

> Hi,
>
> On Aug 2, 2022, at 7:15 PM, Andrew Bird via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
>
> Hi Aitor,
>
> On Wed, 3 Aug 2022 00:37:29 +0200
> Aitor Santamaría  wrote:
>
> Hi,
>
> I am trying to adapt to work with GIT from the GitLab repository, and am
> committing a couple of changes on FD-KEYB that I had ready.
>
> However, I have noticed a problem with the codepages. I try to avoid
> non-ASCII characters, but seldomly use those that are common to most
> codepages.
> What I see is that neither the character stored (that the web omits) or the
> character committed (strange character) are correct, which obviously didn't
> happen when I simply committed a ZIP file with everything:
>
> [image: image.png]
>
> I can live with them and try and take all characters from ASCII, but I am
> just worried if the sources at GIT would all be affected by this apparent
> codepage problem.
>
> Maybe someone more expert on GIT than myself can add something on this.
>
> Aitor
>
>
> The thing is that git stores text files internally as UTF-8, so unless
> any uploaded text file has a match in the .gitattributes file it's assumed
> to be that (or
> binary if can't be interpreted as UTF-8). Consequently any diff shown
> is anybody's guess as to what codepage it might be encoded in. You
> could set .gitattributes to match each codepage which might make sense
> for nls files etc, like I have done for some projects like find (you'll
> see that the diff is rendered properly)
>
> https://github.com/FDOS/find/commit/f763ce94f837e15c2e865e8fc333f8ca8396d427
>  . Though ideally we'd keep all master translation files in UTF-8 format
> and translate to specific codepages at build time.
> If the problematic file is a source code file, then I'd tend to encode it
> in UTF-8 format as any special chars are likely to be in comment sections
> and so have no bearing upon output.
>
> Hope it helps, Andrew
>
>
> There some things I’ve noticed while doing the FD-NLS project on GitHub
> and the Archive on GitLab regarding DOS Codepage files.
>
> Basically, some of the code page translation files, when viewed through
> the web interface, show incorrect characters. However, checking out the
> project (or cloning) it back to a local machine shows the files were not
> changed and the codepage was preserved.
>
> The biggest problem I’ve found is modern editors mangling codepages or
> incorrect codepages being used for a given language. In part that is why I
> started the FD-NLS Desktop App.
>
> Overall, It is probably a good idea to include a UTF-8 version of any
> translated text along with the codepage versions.
>
> Jerome
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] GitLab - problem with codepages

2022-08-02 Thread Aitor Santamaría

Hi,

I am trying to adapt to work with GIT from the GitLab repository, and am
committing a couple of changes on FD-KEYB that I had ready.

However, I have noticed a problem with the codepages. I try to avoid
non-ASCII characters, but seldomly use those that are common to most
codepages.
What I see is that neither the character stored (that the web omits) or the
character committed (strange character) are correct, which obviously didn't
happen when I simply committed a ZIP file with everything:

[image: image.png]

I can live with them and try and take all characters from ASCII, but I am
just worried if the sources at GIT would all be affected by this apparent
codepage problem.

Maybe someone more expert on GIT than myself can add something on this.

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

Re: [Freedos-devel] Another implementation of GRAFTABL

2022-07-12 Thread Aitor Santamaría

Hi,

On Wed, 13 Jul 2022 at 00:22, Steve Nickolas  wrote:

> On Tue, 12 Jul 2022, Aitor Santamaría wrote:
> (I think the PC Convertible is, in fact, the only reason there's even an
> option - it supports loadable charsets, but only in 8x8, so installing a
> full charset, 8x8+8x14+8x16, would be a waste.)
>

It's so long that I last touched DISPLAY, but I seem to remember that the
subdriver may decide where to cut the codepages.
This way, one could write a Convertible sub-driver that cuts them to 8x8
(probably same for CGA).

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

Re: [Freedos-devel] Another implementation of GRAFTABL

2022-07-12 Thread Aitor Santamaría

Hello Steve,

On Tue, 12 Jul 2022 at 12:19, Steve Nickolas  wrote:

> I've been working on this for my own project, and it's only useful for the
> rare CGA or Tandy users out there (which is probably why MS-DOS 6
> relegated it to the Supplemental disk and PC DOS 6 removed it).
>
> GRAFTABL hooks INT1F to provide the upper half of the charset in graphics
> mode on a CGA or Tandy.  (DISPLAY.SYS does this and more on more modern
> display adapters.)  The current version seems to be incomplete - only
> supports a single hardwired codepage? - so I figured I'd offer my own,
> which is my first successful attempt at a TSR that actually does
> something.
>

Once solved the "legal issues", one way to go could be to enrich DISPLAY
instead of making a new driver. DISPLAY is organised as having
"sub-drivers":

DISPLAY CON = (EGA,437,2)

where "EGA" is used to select the sub-driver, 437 is to declare the
codepage that is hardwired in the hardware, and 2 is the number of how many
room for CPIs you want.
Ideally, you could add a "CGA" sub-driver, so that instead of GRAFTABL, one
could issue

DISPLAY CON=(CGA,437,1)

and you save from the TSR stuff, the codepage loading stuff and the
interrupts hooking stuff.

Just an idea that lingered in my mind for a lot of time, although I never
had an enormous interest to care about CGA.

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

Re: [Freedos-devel] FreeDOS interim development build

2022-06-25 Thread Aitor Santamaría

Hello,

Thanks for the answers!


On Sat, 25 Jun 2022 at 22:32, Jerome Shidel  wrote:

> For example, if KEYB on the GitLab archive has a commit pushed with the
> comment “Fixed double keypress bug”. That comment would appear in the
> CHANGES.LOG as something like “2022-06-29 04:52:11 keyb (Aitor Santamaría):
> Fixed double keypress bug”
>

Ok, commit logs are a good source too, but this advices to write good
(user-readable) commit logs.


> Finally, what path on ibiblio do you want to use to provide package
>> updates? This has nothing to do with creating the interim build. As you
>> recall, the current RBE uses the GitLab FreeDOS Archive (
>> https://gitlab.com/FreeDOS) to create the packages on the release. It
>> can also automatically pull specific branches of those packages based on
>> the release, interim, development or other type of build it is creating.
>> The package update url only applies to where the release / interim build
>> will check for package updates.
>>
>> I think it makes sense to keep it along side the other OS update
>> repositories. There are already repositories for each Release
>>
>> 1.1 -
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.1/
>> 1.2 -
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.2/
>> 1.3 -
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/
>>
> I don't know if I am getting this well: this means that in the 1.2 folder
> you find the packages updated over 1.2?
> This means that if at this moment there appears a new updated package that
> hasn't been updated earlier, it should go into ALL of the 1.1, 1.2 and 1.3
> folders?
>
>
> Basically, yes. There is a separate software update repository for
> maintained for each of OS release.
>

It would be for each major, or for every unstable too? (in the latter, it'd
require a lot of space, right?)

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

Re: [Freedos-devel] FreeDOS interim development build

2022-06-25 Thread Aitor Santamaría

Hello Jerome,

I'll give you my opinion on some of these.

On Sat, 25 Jun 2022 at 15:02, Jerome Shidel  wrote:

> First, how will we Label and refer to these builds? I went with “Unstable”
> with the short name would be “FreeDOS U2207” and long name as “FreeDOS
> 2206-Unstable”. To me, it is a well established nomenclature. However to
> the general user base, that may not be the case. We could use “Unstable”
> for now and possible change it later. But, I think we should commit to a
> scheme and stick with it for the foreseeable future.
>
> Should we stick with “Unstable” or use…
>
> Test build; FreeDOS 2207; FreeDOS 2207-TEST
> Development build; FreeDOS DEV2207; FreeDOS 2207-DEVEL
>
Personally, I don't see "DEVEL" as option, as it may give the impression to
be "for developers".
As for the other two, be it TEST or UNSTABLE, I like the idea of YYMM, so
that we get a monthly unstable version that can be downloaded.


> Second, do we want the changes log to go back as far as the previous
> interim build or back to the previous OS release? At present, it limits
> itself to the previous build. But since users / testers will probably not
> test every iteration, I think it may be best to always include everything
> back to the previous official release. At present that would be FreeDOS
> 1.3-Final.
>
I am of the same opinion, go back to the last official.
How do these logs build up? (I am assuming logs in an user-readable
format). Every time someone updates a tool, do we need to fill in somewhere?
Ideally, the implemented bugs and enhancements from GitLab would go to the
list, but I guess the ticketing system is not being widely used. ANother
option would be that every time a new version comes, instead of logging
somewhere else, someone simply logs a new enhancement ticket in GitLab with
the changelog.

Finally, what path on ibiblio do you want to use to provide package
> updates? This has nothing to do with creating the interim build. As you
> recall, the current RBE uses the GitLab FreeDOS Archive (
> https://gitlab.com/FreeDOS) to create the packages on the release. It can
> also automatically pull specific branches of those packages based on the
> release, interim, development or other type of build it is creating. The
> package update url only applies to where the release / interim build will
> check for package updates.
>
> I think it makes sense to keep it along side the other OS update
> repositories. There are already repositories for each Release
>
> 1.1 -
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.1/
> 1.2 -
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.2/
> 1.3 -
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/
>
I don't know if I am getting this well: this means that in the 1.2 folder
you find the packages updated over 1.2?
This means that if at this moment there appears a new updated package that
hasn't been updated earlier, it should go into ALL of the 1.1, 1.2 and 1.3
folders?

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

Re: [Freedos-devel] Thinking about FreeDOS test releases

2022-05-15 Thread Aitor Santamaría

Hello Jim,

My own thoughts:

On Sun, 15 May 2022 at 21:56, Jim Hall  wrote:

> I'm interested in a parallel test distribution that gets updated on a
> regular schedule, by an automated (or mostly-automated) process. Let's
> say there's a new test distribution once a month. Each test
> distribution contains everything in the distribution that's current
> when it was built: packages, installer, translations, documentation,
> etc.
>
> For example, imagine monthly test distributions called "FreeDOS Test
> Build 2022-07," "FreeDOS Test Build 2022-08," FreeDOS Test Build
> 2022-09," ... you get the idea. These don't have a "1.3" or other
> version number on them, only a test build label.
>


> *How we would use this:
>
> We can leave FreeDOS 1.3 distribution as the *stable* release, and
> continue to make changes in the test distribution.
>
> Developers use the monthly test distribution if they want to test
> interoperability with other recent packages. Folks who want to test
> can always find the latest version to experiment with. Translators
> have the latest version. Documenters have the latest version. And so
> on.
>
> The test release label will make it easier to track bugs. "This bug in
> (program) was reported in FreeDOS 1.3, but that problem in (program)
> was fixed since then. Download the latest FreeDOS Test Build and see
> if that fixes it."
>
> At some point in the future (let's use July 2023 as an example) we
> might decide "there haven't been significant changes in the FreeDOS
> test releases in the last year .. we've only seen package updates, no
> big distribution changes .. let's make a 'FreeDOS 1.3 Update1' release
> with the new changes." And then we can promote "FreeDOS Test Build
> 2023-07" as "FreeDOS 1.3U1 RC1" and go through the testing. Bug fixes
> go back into the monthly test release, so "FreeDOS Test Build 2023-08"
> becomes "FreeDOS 1.3U1 RC2," and so on. When testing looks okay, we
> can release "FreeDOS 1.3U1" with very little effort.
>
Well, for this to work, all the updates on the test releases should be
corrective (patches). No new features should be added for this to happen,
otherwise, the test releases will fix some bugs and introduce new ones. For
this reason, it would be useful that the name contains the point version it
is based upon: "FreeDOS Test Build 2023-07 over 1.3" or whatever.

However, it is hard that not all tools would have both fix releases and new
feature releases.
If it were really easy an automated to create new distribution, ideally
there could be two lines: one that patches 1.3 and a second one that goes
toward 1.4.

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

Re: [Freedos-devel] Freedos EDIT

2022-04-23 Thread Aitor Santamaría

Hello,

On Fri, 22 Apr 2022 at 22:28, Eric Auer  wrote:

>
> Hi Tom,
>
> > I just noticed that the source to FreeDOS EDIT
> >
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/base/edit.zip
> > is incomplete as it assumes an existing DFLAT library which is not
> > included, and at least non-trivil to locate on the internet.
>

If you have troubles to find or compile, let me know.


> Looking at my archives, there was a file with the obscure name
> DFP100S.ZIP containing the sources. Such things happened when
> people pretended that web browsers are unable to access files
> with longer names than 8+3 characters :-p
>

Well DOS does not without LFN, and I try to use 8.3 to create DOS packages.

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

[Freedos-devel] FreeDOS on JavaScript

2022-02-23 Thread Aitor Santamaría

Hi,

Remember that in the sunday meeting I mentioned there were out there JS
emulators running FreeDOS?

I've found one in my bookmarks. Running FD 1.2, but still nice to link it
to the main FreeDOS page, so that people can even see the OS in action:

JSLinux (bellard.org) 

I'm sure there are many more out there.

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

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

2022-01-15 Thread Aitor Santamaría

Hi,

For me the last option (use Linux as VMM) would be the most sensible,
needing the least support effort for hardware and drivers: the Linux guys
will do it :)
Hardware-based DOS distributions will never get outdated because Linux
never will.

I think we talked about this option some time in one of the sunday
meetings: in my opinion, the nicest option would be if there was a
sufficiently small Linux distro that could be stripped down up to just
running DOSEMU (or xDOSEMU), maybe just one console, or maybe several (if
that old Ctrl+Alt+Fx is an option).

Just a thought and opinion, I wish I had some spare time myself to get into
such endeavour.

Aitor




On Sat, 15 Jan 2022 at 13:33, Jerome Shidel  wrote:

> Hello all,
>
> I’ve got a couple thoughts regarding the OS release media I wanted to
> throw out to you all. These are just things I was pondering and by no means
> I’m I saying any of these are going to happen. They are just some ideas I’d
> like to share with you and get feedback on…
>
> As you know, the LiveCD uses multiple boot images. A floppy one that
> starts the Live Environment. A second floppy one that launches directly
> into the installer. Finally, a third small hard disk image to run the
> FloppyEdition installer without need for OS level CD support.
>
> Do you think the FloppyEdition installer should be given it’s own entry in
> the CD boot menu? Or, leave it as an “EasterEgg” boot by selecting the
> copyright notice on the menu?
>
> Personally, I don’t see either as a perfect solution. If it is left as an
> EasterEgg, many people will never know it is there. Don’t forget, that
> installer does not need any OS level CD support. If a machine can boot it,
> it can pretty much install FreeDOS on anything. On the other hand, I think
> moving it to it’s own menu item will just confuse users by having 2
> different “Install FreeDOS options”.
>
> Another possibility is drop the current “Install” option. Replacing it
> with the Floppy Edition. Maybe call it something like “Install FreeDOS BASE
> only.” After all, there is no problem running the primary installer from
> the Live Environment. But again, I think users will pick the wrong thing.
>
> This now brings me to the Legacy CD.
>
> It boots using a different process than the LiveCD (See numerous previous
> posts on those differences). This provides CD booting on a narrow range of
> hardware that can boot from CD but not use the method employed by the
> LiveCD. There is a CD Boot Floppy included in the LiveCD download zip
> archive. So, do we really need to keep the LegacyCD around?
>
> The emulated Floppy the LegacyCD boots is the same as the current LiveCD’s
> boot to install menu option. If the LegacyCD sticks around, the image it
> boot’s could be switched to the one used by the LiveCD’s boot to Live
> Environment. This would provide a Live Environment on that legacy hardware.
> But, then what would we call things. They’d both be LiveCDs.
>
> Finally (at least for now), along with the LiveCD and LegacyCD a CD boot
> floppy image is included. We could include a second floppy image to boot
> the Live Environment when direct booting from a CD is not possible. But, it
> could also cause confusion on what to use or burn to CD or Floppy. So, IDK.
>
> I changed my mind. Thats not all just yet.
>
> A lot of users want to run FreeDOS from USB. As I see it, there are
> several issues with that.
>
> First, you cannot guarantee that when booted from USB that drive will be
> writable. Personally, I’ve never seen when it was write protected. But,
> during the early days of developing the installer for 1.2, I learned that
> it was sometimes the case and attempts to use it for temp storage resulted
> in the users machine screaming very loud beeps and throwing write errors.
> So, the installer was modified and always assumes it’s boot media is
> write-protected.
>
> Next, I don’t think users want a temporary Live Environment for USB usage.
> They probably want the programs they install and the changes they make to
> remain for next time. They also probably want the full capacity of the USB
> drive.
>
> That is problematic. Without spending the time to write our own custom
> “Write to USB” program, most will be stuck writing the standard USB images
> directly too the USB media. I don’t see us making our own custom image
> burner to stretch the filesystem for all the major OS platforms. So, that’s
> out for the foreseeable future.
>
> Probably most systems will only do USB HD emulation when booted from that
> USB drive (although I have some machines here that do it even when booted
> from the HD as long as the USB stick is inserted), the best solution I’ve
> come up with has been around for a while. More or less I refer to it as an
> OEM style install. I demonstrated it in a YouTube video with FreeDOS 1.2.
> Basically, you just write the USB install image to the drive. Then boot it
> and exit the installer. Use FDISK to create a separate partition on the

Re: [Freedos-devel] NLS related updates

2021-10-13 Thread Aitor Santamaría

Hello Jerome,

On Wed, 13 Oct 2021 at 03:19, Jerome Shidel  wrote:

> Or…
>
> Should I just incorporate those merge requests. I’m extremely busy at
> present. So, it will have to wait a while. But, eventually I’d get around
> to recompiling KEYB myself. Someday.
>

If the changes are in the layouts, you do not need to recompile KEYB, but
you need the KC/KLIB stuff.

If you are talking about compiling the KEYB driver itself, please leave
this task for the last time, as I may find myself a little piece of time to
recompile it myself (and add the changes that Bret Johnson requested) and
save you from that (many thanks in advance if you do it before I do it).

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

Re: [Freedos-devel] Analysing KITTENC

Hello Jeremy,

In this case (strtoul), the code always assumes the \xdd has only two
numeric characters, i.e. a byte. I suppose that makes sense for DOS
compilers (although the limitation doesn't seem to exist in general:  Escape
sequences in C - Wikipedia
<https://en.wikipedia.org/wiki/Escape_sequences_in_C> ). Thus "\x208"
translates to " 8".
For me \x208 is a bug in the string design for the DOS environment, not "
8".
Curiously, OpenWatcom C  takes only the LAST two digits of the number to
make the character. Thus \x208 becomes \x08 (backspace).

Thus sprintf and processEscChars differ in behaviour (although for this
"buggy" string definition). I suppose that this new function
(processEscChars) is added to avoid problems with the % symbol...

Aitor


On Sat, 21 Aug 2021 at 00:04,  wrote:

> On Fri, Aug 20, 2021 at 4:48 PM Aitor Santamaría 
> wrote:
> >
> > Hi,
> >
> > Thanks Jeremy.
> >
> > On Fri, 20 Aug 2021 at 13:03,  wrote:
> >>
> >> > I was trying to figure out how KITTEN/KITTENC works. Seems to attach
> each NLS file with the "KITTENC" signal by the end of the executable. I've
> read about making UPX support easier, I guess you UPX before you ATTACH.
> >>
> >> It is written to support either, appending before or after UPX, it
> >> stores the original file size and then when ran uses the compressed
> >> file size computing the difference and adjusting the stored offsets
> >> with this difference.
> >> So if you don't compress or append the languages files after
> >> compressing the difference is 0, but if you do it before compressing
> >> then the difference is your compression savings more or less and
> >> offsets adjusted accordingly.
> >
> >
> > But if you append after compressing, wouldn't UPX mess the attached
> stuff?  (I mean if it tries to "expand" something that hasn't been
> compressed).
> > I suppose it is tested to work, but I am curious, I am not very familiar
> with the technical details of how UPX works.
> >
>
> I haven't looked into what exactly it does, but it matters whether you
> are compressing an exe or a com file.
> For exe files, it uses the header (I believe) and only compresses the
> actual executable portion, not anything appended to the file, but
> instead anything after the end of executable portion is copied asis to
> the end of the compressed portion.
> For com files, there is no header, so it can't determine the end of
> the executable portion and anything appended will be treated as part
> of the executable program and thus compressed.  So kittenc and similar
> tools will not work if you append to a com file and then upx - though
> I suppose they could be modified in that case to search memory for the
> strings as upx should both compress and decompress the appended data.
> If you append after compressing, I'm not sure exactly what the upx
> stub does, whether the uncompression has a way to tell the end of the
> compressed data or it will try to uncompress data that wasn't
> compressed (I did a quick but not exhaustive check and a upx com file,
> appending junk, running the com file does not produce any errors
> suggesting upx stub has a way to stop at the end of compressed data).
>  [Note: upx limits com files to about 65350 bytes per its
> documentation]
>
>
> >> > Why did you need to write an own function to convert string to UL?
> >>
> >> It was from the original kitten - not needed in kittenc since that
> >> part occurs during build, but also no need to change working code;  I
> >> like the update from switch statement to strchr for the xlat portion
> >> of the escape conversion
> >
> > Well I see it used when processing the Esc chars, when a language file
> is processed.
> > What I was wondering is if the function is smaller, or has some benefits
> over using the standard strtoul.
> >
> > Aitor
>
> I don't recall (pretty sure it wasn't me who added it), but my guess
> it was either for smaller size like you suggest (it definitely can be
> smaller) and/or because some compilers lack strtoul (not sure how
> many, but at least one lacks it).  However, it should be noted that
> mystrtoul does not match strtoul:
> int mystrtoul (char *src, int base, int size);
> vs
> unsigned long int strtoul (const char* str, char** endptr, int base);
> where src and base are the same for both, one returns a long the other
> an int,  mystrtoul uses size to determine how many numerical
> characters to process whereas strtoul updates endptr to point next
> char after number (if not NULL)
>
>
> Jeremy
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Analysing KITTENC

Hi,

Thanks Jeremy.

On Fri, 20 Aug 2021 at 13:03,  wrote:

> > I was trying to figure out how KITTEN/KITTENC works. Seems to attach
> each NLS file with the "KITTENC" signal by the end of the executable. I've
> read about making UPX support easier, I guess you UPX before you ATTACH.
>
> It is written to support either, appending before or after UPX, it
> stores the original file size and then when ran uses the compressed
> file size computing the difference and adjusting the stored offsets
> with this difference.
> So if you don't compress or append the languages files after
> compressing the difference is 0, but if you do it before compressing
> then the difference is your compression savings more or less and
> offsets adjusted accordingly.
>

But if you append after compressing, wouldn't UPX mess the attached stuff?
(I mean if it tries to "expand" something that hasn't been compressed).
I suppose it is tested to work, but I am curious, I am not very familiar
with the technical details of how UPX works.

> Why did you need to write an own function to convert string to UL?
>
> It was from the original kitten - not needed in kittenc since that
> part occurs during build, but also no need to change working code;  I
> like the update from switch statement to strchr for the xlat portion
> of the escape conversion
>
Well I see it used when processing the Esc chars, when a language file is
processed.
What I was wondering is if the function is smaller, or has some benefits
over using the standard strtoul.

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

[Freedos-devel] Analysing KITTENC

Hello,

Sorry about the SPAM. I found the older thread too long, so I'm starting a
new one with the same content (please comment here if you want to ).

I was trying to figure out how KITTEN/KITTENC works. Seems to attach each
NLS file with the "KITTENC" signal by the end of the executable. I've read
about making UPX support easier, I guess you UPX before you ATTACH.

Why did you need to write an own function to convert string to UL?

By the way, apparently I've found a typo:

if (language &&
_toupper(language[0]) == 'E' &&
_toupper(language[0]) == 'N')
{
// set LANG=EN switches to internal strings


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

Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]

Hi,

I was trying to figure out how KITTEN/KITTENC works. Seems to attach each
NLS file with the "KITTENC" signal by the end of the executable. I've read
about making UPX support easier, I guess you UPX before you ATTACH.

Why did you need to write an own function to convert string to UL?

By the way, apparently I've found a typo:

if (language &&
_toupper(language[0]) == 'E' &&
_toupper(language[0]) == 'N')
{
// set LANG=EN switches to internal strings


Best wishes,
Aitor



On Fri, 6 Aug 2021 at 20:02, tom ehlert  wrote:

> Hi Robert,
>
> am Freitag, 6. August 2021 um 19:44 schrieben Sie:
>
> > Hi Jim,
>
> >> Good to see this update. I look forward to trying this out.
> >>
> >> One comment from reviewing the code - you use this comment at the top
> >> of both kittenc.c and kitten.c:
> >>
> >>> /*
> >>>   This software is free software; free to use,
> >>>   modify, pass to others, whatever
> >>>
> >>>   use it at your own risk
> >>> */
> >>>
> >>
> >> However, you don't include a license file (usually LICENSE.TXT or
> >> COPYING.TXT) to indicate what "free software" license you are using.
> >> Can you be more specific? Is this under the GNU GPL? GNU LGPL? MIT?
> >> BSD? Apache? Or some other license?
>
> > His comment sounds like Public Domain to me.
>
> it's intended to be as free as possible. I don't even care if the evil
> satan (MS or Oracle) uses, modifies or whatever does with it.
>
>
> > kitten.h is LGPL. Dunno if this is compatible.
> thanks for noting this. will change this as soon as possible.
>
> BTW: since the big fight of Oracle vs. Google wrt JAVA include files
> we all know that .H files aren't even copyrightable.
>
> also: by german law, for copyright claims your software (or other
> thing) has to have a minimum 'invention hight'. KITTEN.H certainly has
> no 'invention highness'.
>
> so: there shouldn't be a copyright on it in the first place.
>
>
>
> > I tend to dislike this license stuff...
> so do I
>
> Tom
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]

2021-08-09 Thread Aitor Santamaría

On Mon, 9 Aug 2021 at 20:16, Robert Riebisch  wrote:

> Hi Aitor,
>
> > I've noticed you Germans have your quirks with the spelling because
> > there was a change to standardise the ortography not long ago  (when to
> > use ss and eszett amongs others :)).
>
> The last big reform was in 1996.
>
> But this reform has been reformed in 2004, 2006, 2011, 2017, and 2018.
> *lol*
>

Nice. I've heard German language teachers here complaining about textbooks
needing to be changed, hopefully not 5 times! (and some taking the more
"practical" approach: why bother with standard German, teach Bavarian and
hope the student will travel to Bavaria or be somehow understood everywhere
else lol).

Trying to get back on-topic, I suppose it will not change the collating
tables or upper/lower case of NLSFUNC at all, right?

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

Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]

2021-08-06 Thread Aitor Santamaría

On Fri, 6 Aug 2021 at 21:11, Ralf Quint  wrote:

> > Insights from native english/american  (English/American) people?
> >
> I learned this from my first English class in school, pretty much 50
> years ago... ;-)
>
>
Sadly enough, get ready that it may change at any point quickly. When I was
a kid, in Spanish we used to write the names of the days and months with
capital letter, being a "proper noun" (in my opinion, it is a proper name).
But a rule at some point (in my childhood) dictated that we should not.  I
still write "Septiembre", let the translator do that for me if it wants to
;)

For some reason, in Spanish at some point they decided that it is "bad
taste" to abuse capital letters here and there. I am not sure how it is in
English, but I seem to remember it is in capital letters (like September
and not september).

What's more, things change because of how people pronounce them. So now
"setiembre" is accepted because nobody says the "P" any more.

Another annoying stuff is when punctuation signs change too. For example,
we are taught in schools that the decimal separator (the equivalent to dot
. in English) is ' in Spanish (I've also read that the Academy of Physics
prescribes so) like in  3'14159, but *everybody* uses comma in Spain. like
in 3,14159  and even Microsoft Excel considers the separator to be ,
because everyone does. I can't remember what we do have in NLSFUNC, or if
we need to have both "stanard Spanish" and  "real used Spanish"  :)

I've noticed you Germans have your quirks with the spelling because there
was a change to standardise the ortography not long ago  (when to use ss
and eszett amongs others :)).

Last but not least, having learnt my English in the UK, I had to learn to
either change the spelling dictionary in GMail to British English or
replace "standardise" with "standardize" in my previous sentence ( :D ).
As a plus, I still don't know the preferred way to pronounce "either" (if
there is one) because I've heard many different options. At least, I know
how to pronounce "early", unless we don't know what shall we do with a
drunken sailor.

Oh well.

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

Re: [Freedos-devel] video FreeDOS running Windows 3.1

2021-07-26 Thread Aitor Santamaría

That is very good news IMHO, Jeremy!!
Sure a thing to wait for, for FreeDOS 1.3 release.

I think it is a meaningful milestone (even if there is not many people
running Win3.X that wouldn't do it over MS-DOS), but very relevant all the
same.

All the best,
Aitor



On Sat, 24 Jul 2021 at 08:02,  wrote:

> Hello all,
>
> I thought some of you might enjoy this (others may really dislike it).
> Link is to a (posted to YouTube) about 2 minute video of (version
> 2043+patches) FreeDOS kernel running Windows 3.1 in Enhanced and
> Standard mode.  I haven't pushed the changes to the public GitHub
> repository yet as there are still some rough edges to fix (all the
> changes are technically there, just in the old unstable branch).  I
> will make a test version (with source) available later this week along
> with steps to run Windows.  [I need to go to sleep now.]
>
> https://youtu.be/35OQjLYdvJ0
> (I apologize for anyone that can't view the video - it is just FreeDOS
> kernel booting in VirtualBox, me running a bunch of ver /r commands
> and WIN along with a dos prompt, and showing both enhanced and
> standard mode.)
>
> For the technical aspect - the changes are minimal to the kernel,
> added support for a few int 2F function calls that were never merged
> in was about all it took.  All significant changes behind a
> WIN31SUPPORT #ifdef so doesn't need to be compiled in if unwanted.
>
> Enjoy,
> Jeremy
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] changing keyboard layout

2020-12-12 Thread Aitor Santamaría

Hello Bret  (and the rest):

On Fri, 11 Dec 2020 at 17:00, Bret Johnson  wrote:

> The interaction between the screen (Code Page) and Keyboard is pretty
> critical so that everything is displayed correctly.  In addition to
> DISPLAY, DOS has other "utilities" like "CHCP", "MODE CON CODEPAGE
> PREPARE", and "MODE CON CODEPAGE SELECT" to manipulate the screen and it
> all must interact correctly with KEYB.  In addition, many (if not all) of
> the KEYB languages will work with two different screen Code Pages (a
> primary and an alternate) and must know what the current Code Page is to
> work correctly.  There are even ways to manipulate the screen so you can
> get 512 different characters instead of just 256.  It can be VERY confusing
> to set things up correctly, especially if you're using an "unusual"
> language.
>

It is indeed very complex. Actually, you should avoid "MODE CON CODEPAGE
SELECT", even if MS-DOS boot disk used this command. Using MODE CON CP
SELECT leaves kernel and CON device (i.e. screen+keyboard) misaligned.
I suppose Microsoft did so as they didn't want to get NLSFUNC to the
bootdisk (NLSFUNC adds this codepage aware functionality to kernel). And
because if you use COUNTRY=... in CONFIG.SYS, then you don't need NLSFUNC
(it is very unlikely that you'll want to change the codepage) and thus the
COUNTRY= and MODE CON CP SELECT works. They wouldn't care about printer's
codepage :)

The correct sequence would be:

load the nls functionality:
DISPLAY.SYS/.COM   (in CONFIG.SYS for MS-DOS, in AUTOEXEC for FreeDOS)
PRINTER.SYS (in CONFIG.SYS, MS-DOS only)
NLSFUNC

prepare all the devices for the codepages you want to use:
COUNTRY= ...  (in CONFIG.SYS)
MODE  CP PREPARE=...
MODE  CP PREPARE=...
MODE  CP PREPARE=...
...

And then, change the codepage everywhere at once with CHCP:
CHCP 850

> And none of this even addresses what happens if you try to print something
> to a printer since a printer "Code Page" doesn't necessarily match what's
> on the screen.  As long as you limit yourself to the first 128 ASCII codes
> you usually don't have problems.
>

This would be PRINTER.SYS' job.
I was tempted to write a PRINTER.SYS myself years ago, but I lack the
information of which printer commands are needed to load/prepare a codepage
(MODE CON CP) and how to select it. I guess this information is
printer-specific, and I don't know if it is compiled somewhere (links are
welcome :)).
I think MS-DOS  PRINTER.SYS will not work in FreeDOS (unless I missed
something), as MODE xxx CP SELECT is only implemented to interact with
FreeDOS' DISPLAY  (and I am not sure of how FreeDOS NLSFUNC is implemented,
whether it would do the GENIOCTL call for every character mode device.

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

[Freedos-devel] DOS (and BIOS) references

2020-12-09 Thread Aitor Santamaría

Hello,

Incidentally I came across this DOS/BIOS reference (that I found cool
looking) and wanted to share it with you,

Tech Help! (dos4gw.org) 

I don't know how up-to-date it is. I know that this topic pops-up from time
to time, but I haven't heard any RBIL update for quite a while (last known
version is 61 from year 2000?). These are the sites I know to hold such
kind of information, and I was wondering if you knew of more that are
worth, or know of any that is being updated to some extent:

RBIL - Ralf Brown's Files (cmu.edu) 
Ctyme - Ralf Brown's Interrupt List - HTML Version (ctyme.com)

(sadly, apparently Marc Perkel passed away)
RBIL61 - HTML Edition (lod.bz)    - Bing gave this
to me, apparently there's a program called RBILtoHTML
Delorie - Ralf Brown's Interrupt List (delorie.com)


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

Re: [Freedos-devel] changing keyboard layout

2020-12-09 Thread Aitor Santamaría

No problem!

The original note that Matthias Paul wrote a long time ago was very
interesting, but a very long post too :)


On Wed, 9 Dec 2020 at 20:43, tom ehlert  wrote:

> > * KEYB does not hook int 2Fh just for installation check. KEYB is
> > "codepage aware", as it has produce the appropriate character code
> > for that particular codepage (font), and that is why INT 2Fh/AD81h
> > exists: DISPLAY will call KEYB whenever there's a codepage change
> > request, so that KEYB keeps aligned with the current codepage.
>
> I wasn't aware of this. Thanks for correcting.
>
> Tom
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] changing keyboard layout

2020-12-09 Thread Aitor Santamaría

In addition to what Tom said (and regarding KEYB):
*   int 09 calls int 15h/4Fh is guaranteed for PC/ATs. For older keyboards
where it does not happen,  /9 option will hook the int9h handler to
precisely add this call to the present int9h handler.
* KEYB does not hook int 2Fh just for installation check. KEYB is "codepage
aware", as it has produce the appropriate character code for that
particular codepage (font), and that is why INT 2Fh/AD81h exists: DISPLAY
will call KEYB whenever there's a codepage change request, so that KEYB
keeps aligned with the current codepage.

Maybe you can find out more on this topic here:

'Re: [fd-dev] Changing codepages in FreeDOS' - MARC

Aitor

On Wed, 9 Dec 2020 at 19:40, tom ehlert  wrote:

>
> > After installing new layout and calling int 15h/4Fh manually,
> > causes correct scan code / ascii code pair is enqueued into the
> > keyboard buffer and carry flag isn't set because something is
> > changed this time. In short, this function is responsible for
> > changing keyboard layout, obviously. But how? I mean, how do
> > keyb.com know where exactly code page is in memory.
>
> KEYB doesn't know. AT ALL.
>
> KEYB translates scan codes (as transmitted form the keyboard) to
> 8 bit codes according to the keyboard language.
>
> ascii is the wrong term here.
> ASCII is defined (mostly) for the lower 128 of 256 characters, like
> the usual aAbBcB...zZ1..9.,;:...  that are common to most languages.
>
> as there is not enough space above 128 to have all possible russian,
> greek, spanish, indonesian, ...  codepages where invented.
>
> codepages assume a particular character set which differs for each
> language.
>
> most likely (I am no language expert) the code 0x31 will display
> identical (as '1') in all codepages, but 0x99 will display differently
> for greek and russian. it's probably best to think of 'codepages' as
> 'fonts'.
>
> Tom
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS is 25 years old

2019-07-02 Thread Aitor Santamaría

Yeah indeed! A milestone to celebrate.
Glad to be part of the community, and long future for FreeDOS!


On Mon, 1 Jul 2019 at 00:34, Jim Hall  wrote:

> FreeDOS has now been around for 25 years. That's a major milestone for
> anything, especially an open source software project.
>
> I just wanted to say THANK YOU to everyone in the FreeDOS community - past
> and present. Open source software is about people coming together to work
> on something, and that's you. If I ever meet any of you in person, I'll buy
> you a beer/beverage.
>
> And it's great that our community remains so positive. So THANKS for
> helping keep out the trolls.
>
> I'm looking forward to FreeDOS 1.3! :-)
>
>
> Jim
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] keyb us does not work

2016-11-13 Thread Aitor Santamaría

Hello Paul,


On 6 November 2016 at 17:17, Paul Dufresne  wrote:

> When it work, it detects the other version running:
> different version of KEYB found 594003C != d0f4003c
>
> Is it the address of KEYB instances?
>
Depending on the exact message, would mean a different version, different
driver...



> Ok, anyway, it is not what I was expecting.
> I expect DOS to have a table of 256 scancodes to ASCII (well extended
> with 128 code-page specific characters)
> values. I expect this table to be changed by KEYB, not to stay
> resident in memory.
>
What do you exactly mean by a table of 256 scancodes? KEYB would map some
key/scancodes to others, overriding BIOS. Thus, it requires to be resident.

If you mean character maps, then it is about the display, not the keyboard,
and you actually need DISPLAY. It needs to be resident, because some
changes do reset character maps, and you need a DISPLAY that keeps
controlling that codepages do not change.


> I just look a bit this table is BIOS related, not DOS related.
>
KEYB is a "driver", but not a standard DOS driver, but works as a BIOS
extension/override.
DISPLAY would theoretically be a estándar DOS driver extension (extending
CON), but does actually work as a BIOS override too.
So yes, it is BIOS related, not DOS related.

It seems it should be pointed by interrupts vectors:
> 48 BIOS PCjr cordless keyboard translation
> 49 BIOS PCjr non-keyboard scancode translation table
>
I haven't looked into this, but sounds like PCjr, not standard PC.


> Oh well, not sure at all if it is really used by most BIOS.
> Maybe I should like inside SEABIOS code.
>
> This table should be used by Int 16h (BIOS).
>
> Maybe I should begin by trying to understand why there is keyb, and mkeyb.
> :-)
>

They work similarly, but mkeyb is smaller and hardcoded (unless changed in
the previous times and I didn't notice), keyb is bigger and programmable
(you create your own mappings if you want). Depending on your needs.

Aitor
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] keyb us does not work

2016-11-06 Thread Aitor Santamaría

Hello,

I can't remember exactly how US.KEY was defined but, in most cases that I
know, PC BIOS preassumes that keyboard layout by default is US style, and
you use a "key-like" program to change it. I guess that US.KEY really makes
very few changes to current layout, thus you mostly continue to see the
same layout that you had before using KEYB US.

So first of all would be, are you using any other "keyb-like" program that
gets loaded before or after KEYB?
And if you are not, it would really mean that your BIOS has AZERTY layout
hardcoded, what sort of machine is that?

Best wishes,
Aitor

On 6 November 2016 at 05:14, Paul Dufresne  wrote:

> After installing in french, I get french keyboard...
> you might find it strange, but here in Quebec, we are totally lost
> with french keyboard.
>
> US is much more usable for us.
>
> But then, when I type
> keyb us
>
> the 2 output lines, seems to suggest that it worked.
>
> But I still have AZERTY (french) keyboard layout rather than the
> QWERTY one we are used
> here.
>
> Someone would know why?
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] A little message

2016-01-01 Thread Aitor Santamaría

The best wishes for everyone in this list for the forthcomming (now
current) 2016.
( Feliz 2016 for Spanish speakers).

May this symbolic year (16 for a mostly 16-bit operating system) be a
good FreeDOS year.

Aitor



On 1 January 2016 at 11:53, Maarten Vermeulen  wrote:

> Wow, that should be our slogan! :D
> --
> Van: Mercury Thirteen 
> Verzonden: ‎1-‎1-‎2016 09:01
> Aan: Technical discussion and questions for FreeDOS developers.
> 
> Onderwerp: Re: [Freedos-devel] A little message
>
> Why did he do it? because FREEDOS! :D
>
> On 12/31/2015 7:44 PM, JAYDEN CHARBONNEAU wrote:
>
> Yeah.I used FreeDOS to hack the Matrix to access the webcam.Hahah. :)
> On Dec 31, 2015 6:39 PM, "Maarten Vermeulen"  wrote:
>
>> It is 1 january here (00:36). So happy new year :)
>>
>> The time in the Netherlands is about 6 hours later then in New York.
>>
>> Maarten
>> --
>> Van: JAYDEN CHARBONNEAU 
>> Verzonden: ‎1-‎1-‎2016 00:14
>> Aan: Technical discussion and questions for FreeDOS developers.
>> 
>> Onderwerp: Re: [Freedos-devel] A little message
>>
>> See you guys next year! (Hah...hah..hah?)
>> On Dec 31, 2015 10:29 AM, "Mercury Thirteen" 
>> wrote:
>>
>>> Then a happy New Year to all those of us who are still stuck in last
>>> year! :P :)
>>>
>>> On 12/31/2015 9:39 AM, Mateusz Viste wrote:
>>> > I fear you are slightly too late - there are many places in the world
>>> > where it's 2016 already - Most of Australia, some parts of Russia, New
>>> > Zealand, and a few more. :)
>>> >
>>> > Mateusz
>>> >
>>> >
>>> >
>>> > On 31/12/2015 15:09, JAYDEN CHARBONNEAU wrote:
>>> >> Yes,tonight is New Years Eve!Stay up late!Party!Watch the balldrop!I
>>> you
>>> >> all have a wonderful (and crazy) evening!
>>> >>
>>> >> -Jayden
>>> >>
>>> >> *Crazy meaning have a fun party
>>> >>
>>> >> On Thu, Dec 31, 2015 at 2:52 AM, Maarten Vermeulen <
>>> netraa...@gmail.com
>>> >> > wrote:
>>> >>
>>> >>  And a happy new year! :)
>>> >>
>>> >>
>>> >>
>>> 
>>> >>  Van: JAYDEN CHARBONNEAU 
>>> >>  Verzonden: ‎26-‎12-‎2015 16:07
>>> >>
>>> >>  Aan: Technical discussion and questions for FreeDOS developers.
>>> >>  
>>> >>  Onderwerp: Re: [Freedos-devel] A little message
>>> >>
>>> >>  I recently got my band director to let us play Sleigh Ride.The
>>> >>  trumpets enjoyed making the horse noises.
>>> >>  On Dec 26, 2015 3:19 AM, "Maarten Vermeulen" <
>>> netraa...@gmail.com
>>> >>  > wrote:
>>> >>   >
>>> >>   > For those who like it, a Dutch christmas song.
>>> >>   > 'midden in de winternacht' it's name. This is one of the first
>>> >>  christmas songs you learn in dutch, because this one is always
>>> used
>>> >>  on school.
>>> >>   >
>>> >>   > So here is it, 'midden in de winternacht'.
>>> >>   >
>>> >>   > https://m.youtube.com/watch?v=lOyEmKJozc0
>>> >>   >
>>> >>   > Of course you are allowed to use google translate :)
>>> >>   > 
>>> >>   > Van: Rugxulo
>>> >>   > Verzonden: ‎26-‎12-‎2015 06:09
>>> >>   > Aan: Technical discussion and questions for FreeDOS
>>> developers.
>>> >>   > Onderwerp: Re: [Freedos-devel] A little message
>>> >>   >
>>> >>   > Hi,
>>> >>   >
>>> >>   > On Fri, Dec 25, 2015 at 12:37 PM, Maarten Vermeulen
>>> >>  > wrote:
>>> >>   > >
>>> >>   > > Yes thanks! Everyone have a merry christmas!
>>> >>   > > Good luck with your familly! :P
>>> >>   >
>>> >>   > What, no Dutch translation?  :-O
>>> >>   >
>>> >>   > "Gelukkig Kerstfeest!" (according to
>>> https://translate.google.com)
>>> >>   >
>>> >>   > (And the German ...)
>>> >>   >
>>> >>   > "Fröhliche Weihnachten" (also according to Google)
>>> >>   >
>>> >>   > (Kaj la esperantan tradukon ...)
>>> >>   >
>>> >>   > "Feliĉan Kristnaskon!"
>>> >>   >
>>> >>   >
>>> >
>>> >
>>> --
>>> > ___
>>> > Freedos-devel mailing list
>>> > Freedos-devel@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>>
>>>
>>>
>>> --
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>>
>>
>>
>>

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

2015-04-04 Thread Aitor Santamaría

Hi,

And that's such a sad news, if Japheth's software cannot be accessed
anymore.

Oh well...
Aitor


2015-04-04 22:08 GMT+02:00 Rugxulo rugx...@gmail.com:

 Welp, it was fun while it lasted 


 On Fri, Jan 2, 2015 at 5:22 PM, Aitor Santamaría aitor...@gmail.com
 wrote:
  Thank you Rugxulo!

 If you thank me for good things working, which I didn't do, then you
 must also blame me when things go wrong. As such, blame away.

  I always was somewhat concerned about such licensing issues, but the
  software looks pretty valuable!  :)

 Certainly valuable. That's why a lot of us used it. Heck, presumably
 that's why he shared it with the world in the first place.

 Unfortunately, it doesn't work anymore:

 Page cannot be crawled or displayed due to robots.txt.

 http://web.archive.org/web/20140526051314/http://japheth.de/robots.txt

 
 User-agent: *
 DisAllow: /cgi-bin
 

 I have no idea why they decided (now) to enforce that, after all these
 months. The original site is still down. AFAIK, the software itself is
 still freeware (although not totally free/libre). I don't know if this
 was Japheth's wish (doubt it, but he's very eccentric) or if it's just
 some default setting somewhere. Color me naive. I don't think the
 world is a better place now.

 Jim Hall will probably say, That's what you get for not being
 free/libre in the first place. And he's probably right.


  2015-01-02 23:24 GMT+01:00 Rugxulo rugx...@gmail.com:
 
  On Fri, Jan 2, 2015 at 1:39 PM, Aitor Santamaría aitor...@gmail.com
  wrote:
  
   PS: Btw, I continue to be a bit worried about [  www.japheth.de  ],
   anyone?
 
  http://web.archive.org/web/20140904175113/http://www.japheth.de/HX.html
 
  Also, dare I mention, the licensing is a bit ambiguous. Great if all
  you care about is freeware, lousy if you're a free software
  zealot. So don't expect many (if anybody) else to mirror it anywhere.


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

2015-01-06 Thread Aitor Santamaría

Hi,

I have to admit the difference between what I'd like to see and what I
think it is likely to happen.
I had found Japheth's work promising towards a good VMM, but apparently
doesn't seem to be under active development, I find the task would be so
huge (need to rewrite 32-bit versions of BIOS/DOS APIs capable of multitask
different machines), and there's no abundance of gifted programmers.

So I'm afraid I give +1 to this mail.

I suggest concentrating efforts on FreeDOS 1.2.

As for FreeDOS 2.0, we can always talk later (as I see it, either there's
no consensus on what 32-kernel is, or if it has to be 16-bit, I think
recovering the talk is needed, I would like to see what is proposed to be
labelled 2.0 instead of 1.3).

Cheers,
Aitor




2015-01-06 3:16 GMT+01:00 Ralf Quint freedos...@gmail.com:

 On 1/5/2015 6:14 PM, Michael Brutman wrote:
  Bringing things back to reality:
 
  Options 1, 2, and 3 do not exist and are not likely to exist for a few
  years even after somebody actively starts working on them.
 
  Options 1 and 2 can not promise 100% compatibility with both DOS
  applications and the full range of PC hardware when they are not even
  well defined.  Is it a single 32 bit kernel or is it multiple kernels
  running in VDMs?  I've seen so many things thrown around here so
  loosely ...
 
  It is a little silly to keep talking about a 32 bit kernel on the
  roadmap when such an option does not exist.  To be considered for the
  roadmap it should exist in some form.  Right now it is not even well
  defined what a 32 bit kernel would be.  Not even a specification that
  we can debate.
 
  Let's see some concrete results on a 32 bit kernel before talking
  about putting it on any roadmap.
 
  BTW, the Kickstarter project doesn't even clearly define what a 32 bit
  DOS is.  But at least its being honest and not promising 100%
  compatibility on anything.  It is claiming to be hard real-time,
  modular, based on a micro-kernel, multi-threaded, and portable enough
  to be able to target ARM and some other architectures.  That's a
  pretty bold set of buzzwords, but not a specification by any stretch
  of the imagination.
 
 Now on this post, I can give a +1 ;-)

 Ralf

 ---
 This email has been checked for viruses by Avast antivirus software.
 http://www.avast.com



 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

2015-01-03 Thread Aitor Santamaría

Hello,

2015-01-03 19:14 GMT+01:00 Travis Siegel tsie...@softcon.com:


 On Jan 1, 2015, at 3:46 AM, Mercury Thirteen wrote:

  I too would love to see a fully modern DOS.

 As would I, and I believe everything mentioned in the email would be
 perfect for a 32-bit dos.  I believe it can be done, and the whole give
 each program it's own virtual 86 machine is one I've wondered about for
 quite sometime.  It shouldn't be difficult, and actually, I read somewhere
 that the initial version of windows did this, but of course, I can't
 confirm that, since the only version of windows 1.0 I ever had was on an xt
 where such a scheme wouldn't have worked anyhow, not to mention, I haven't
 a clue where that machine wound up at. :)
 Otherwise, each program being spawned in it's own virtual 86 machine, and
 leaving things in protected mode as much as possible makes perfect sense to
 me, and it was what I'd figured would happen to dos eventually, but it
 never did.


It actually did!
This is exactly what I was trying to explain, this is the way Microsoft
took, as this is what VMM32.VXD=DOS386.EXE does  (a much overpowered
EMM386.EXE).
But Microsoft didn't sell this piece of software with MS-DOS, but with
MS-Windows.

Cheers,
Aitor







 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

Hi,

I myself agree with the first and third point.

About the second, I'm not advocating for a different 32-bit OS (such as
FreeDOS-32). I also agree that one first target would be the UEFI stuff.
But at long term, I am of the opinion that VxDs are DOS drivers, as much as
the classic DEVICE= drivers are, and that is a neat way of preserve
running 16bit programs on a bubble and protected from the outside 32/64-bit
world  (and that in addition to CONFIG.SYS, has a file called SYSTEM.INI
for configuration and listing of which drivers are loaded; and a SYSTEM.INI
that has nothing to do with WIN.INI).

If FreeDOS 2.0 is going to be purely and completely 16-bit, in what differs
FreeDOS 2.0 from FreeDOS 1.3?

Aitor

PS: Btw, I continue to be a bit worried about [  www.japheth.de  ], anyone?




2015-01-02 2:31 GMT+01:00 Jim Hall jh...@freedos.org:

 It seems clear a consensus is appearing, but I'll give folks another few
 days to chime in. That will give me time to continue on website cleanup
 things, anyway. :-)


 *What I think I'm hearing: (and I agree)*

 *- FreeDOS 1.2 should be an update/refresh from FreeDOS 1.1. No major
 changes. Improved installer is a good idea.*

 *- FreeDOS 2.0 should be 16-bit. Make FreeDOS feel more modern, but keep
 it DOS. We can improve the userspace. Keep supporting old PCs, but
 support new hardware where we can. UEFI may be tricky (see SeaBIOS
 discussion).*

 *- If FreeDOS-32 will break DOS application compatibility, it should not
 use the FreeDOS name.*


 Agree or disagree with these points? Did I miss anything? Other discussion?


 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

Hi,

Not only about kernels, but about the 16-bit DOS compiling options too.
I think we talked about this in the past, and I think it'd make sense that
FreeDOS 2.0 would be 386+.

Aitor

2015-01-01 23:43 GMT+01:00 Mercury Thirteen mercury0x0...@gmail.com:

 Speaking of multiple kernels, would it be acceptable to require a minimum
 hardware platform for a new version of FreeDOS? Could we exclude the
 pre-386 crowd without backlash? Personally, I think that's acceptable and
 I'm sure Microsoft would've no doubt done the same thing by now had they
 not gone to Windows. There's no way they would still include the 8086 and
 80186 in their modern MS-DOS, had they made one.


 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

Hi,

I don't know how that can run in real mode by default differs from
current situation.
Maybe you mean that FreeDOS drops EMM386.EXE.

Regards,
Aitor

2015-01-02 20:47 GMT+01:00 sparky4 spar...@cock.li:

I think the FreeDOS 2.0 version should be a updated 16 bit kernel that can
run in real mode by default

and the freedos-32 stuff should merge with OSFree

--
View this message in context:
http://freedos.10956.n7.nabble.com/FreeDOS-1-2-and-2-0-roadmap-discussion-tp21529p21578.html
Sent from the FreeDOS - Dev mailing list archive at Nabble.com.

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is
your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

Hi,

That's my guess:

2015-01-02 0:05 GMT+01:00 cordat...@aol.com:

 If you take a look one of the links from Jim recently he states:

 But in an alternate reality, what would DOS had looked like if Microsoft
 *hadn't* moved to Windows? I think we get to define what that looks like.


My guess is that if Windows (the GUI) hadn't existed, then DOS386.EXE would
have been packed with MS-DOS, it would have never been renamed to
WIN386.EXE or VMM32.VXD, and MS-DOS would have had a wonderful multitasker
that allows you to switch between different MS-DOS sessions, and thus fully
profit from the power of a 386.

My guess is that the decision to pack DOS386.EXE with Windows (3.X+) and
not with MS-DOS was a commercial one, to push the market into Windows, and
not a technical one (just as the abilities of the NT kernel to run POSIX
and OS/2 applications were underdeveloped).

Commercially wise, but a pitty for software with such a huge potential  :)



 Think for a second about what Microsoft, or any company would have done to
 continue DOS development ?

 They would have started by trying to understand what users would be doing
 with the new software.  What kinds of things are users requesting that
 can't be done with MS-DOS 6.22 ?  What could we do to increase market share
 for DOS compared to other operating systems?


 In my opinion, users usually like to run classic apps but profiting from
new hardware's capabilities. 386 gives you a way to access huge amounts of
memories and multitask, and that can be done in a 100% DOS flavour (as
DOS386/VMM32 proves).

But I am repeating my arguments from other mails, I hope I managed to
explain my position this time  :)

Cheers,
Aitor
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

Thank you Rugxulo!

I always was somewhat concerned about such licensing issues, but
the software looks pretty valuable!  :)

Aitor

2015-01-02 23:24 GMT+01:00 Rugxulo rugx...@gmail.com:

 Hi,

 On Fri, Jan 2, 2015 at 1:39 PM, Aitor Santamaría aitor...@gmail.com
 wrote:
 
  PS: Btw, I continue to be a bit worried about [  www.japheth.de  ],
 anyone?

 http://web.archive.org/web/20140904175113/http://www.japheth.de/HX.html

 Also, dare I mention, the licensing is a bit ambiguous. Great if all
 you care about is freeware, lousy if you're a free software
 zealot. So don't expect many (if anybody) else to mirror it anywhere.


 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

2015-01-01 Thread Aitor Santamaría

Hello Jim and all,

I like the idea of having two releases of FreeDOS with different goals: a
FreeDOS 1.2 as an update of current FreeDOS 1.1, in order to have something
on a short term as an update of current distribution.

As for FreeDOS 2.0, I share my ideas here. I agree that it should be a big
leap forward on the development of FreeDOS, and as my biggest worries are
the disappearing of BIOS and 16-bit mode, they are about moving to 32-bit.
Three possibilities:

(1)  My favourite would be to develop something similar to Microsoft's
VMM32.VXD:  a 32-bit kernel that would allow you to run different
16-bit/32-bit VMs, with expansion by 32-bit drivers (the VXD) that
emulate BIOS and control the VM interoperativity.
With some help (multithreading), and some software to run EXE-PE's and
DLL's, FreeDOS could expand not only to running DOS-16bit apps, but also
legacy Win32 apps (e.g. console ones). With quite an effort, this scheme
may be extended to run Win16, POSIX (minGW?) or OS/2 apps.

Booting could start with 16-bit, and then execute the extender, or
alternatively, set a bootstrap sequence (set by SYS) to directly run the
extender.

The disadvantage is that this is quite a lot of work, I think Japeth has
moved on this way, so there's something where to start. The advantage is
that DOS would retain much of its flavour, and continue the tradition
to run legacy Microsoft software.


(2) A second option would be that, instead of a new 32-bit kernel, we use
Linux: you boot a Linux without anything extra, and that simply runs DOSEMU
(or different consoles with different DOSEMU's, in order to emulate to have
different VM's). My plan was to pick a Linux distribution and start
stripping it down to simply boot DOSEMU.

The advantage is that FreeDOS would live as long as Linux lives (and no
matter if it moves to 64-bit), that is, forever. The disadvantage is that
it would mean moving to a native POSIX world, it may loose some of the DOS
flavour, and everything that does not work on DOSEMU, would not run on
FreeDOS 2.0.


(3) Go the FreeDOS-32 way that you mentioned. The advantage is the total
freedom and unconstrained start for a 32-bit kernel, based on what's there.
The disadvantage is that it may also require a lot of work, and that it may
be to start a work compatible with nothing that already exists.


I just thought I should mention them before entering a critical way that
requires a lot of work.


Cheers and happy 2015 to everyone.
Aitor





2014-12-31 23:51 GMT+01:00 Jim Hall jh...@freedos.org:

 Mike pointed out that the FreeDOS Road Map
 http://www.freedos.org/wiki/index.php/FreeDOS_Road_Map (wiki) is out of
 date and short on details and suggested a broad discussion on the road map,
 get consensus and have it updated.

 I figured we should start a separate discussion thread about that.


 First, a little history on the road map:


 When I started FreeDOS in 1994, the goal was to create a free version of
 DOS, compatible with MS-DOS. (original PD-DOS announcement
 https://groups.google.com/d/msg/comp.os.msdos.apps/oQmT4ETcSzU/O1HR8PE2u-EJ)
 (original Free-DOS manifesto
 https://groups.google.com/d/msg/comp.os.msdos.apps/W6MuhF__R9s/MgdzBrlanTwJ
 )

 That aim remained essentially the same for a long time. And I believe we
 met that with version 1.0 a few years ago. FreeDOS 1.1 was an update to
 FreeDOS 1.0, so things didn't really change there.

 In 2009 http://www.freedos.org/jhall/blog/?id=20090511-192954, I
 briefly stepped away from FreeDOS to focus on a graduate program (I ended
 up changing jobs instead, and didn't do the M.S. program until a few years
 later). During that time, Pat Villani stepped in as project coordinator.

 Pat wanted to do something to spur development, so in 2010
 http://www.freedos.org/wiki/index.php?title=FreeDOS_Road_Mapoldid=845
 he wrote the first version of the FreeDOS Road Map (see old version
 http://www.freedos.org/wiki/index.php?title=FreeDOS_Road_Mapoldid=845).

 In 2011 http://www.freedos.org/jhall/blog/?id=20110502-164858, Pat's
 health was getting worse, so I came back as project coordinator. Nothing
 had been done on the road map, so I replaced it with a copy/paste from a
 blog post I had written earlier (see blog post
 http://www.freedos.org/jhall/blog/?id=20110502-164858) until I could go
 back and update it for real later on.

 A few days ago, Harold (aka Mercury Thirteen) mentioned the road map on
 the wiki. I realized I never updated the road map, so I tacked a THIS PAGE
 IS OUT OF DATE notice at the top of the wiki entry.

 More recently, Chelson announced on our Facebook group
 https://www.facebook.com/groups/freedos/ his kickstarter project to
 fund development of FreeDOS-32, with the hope that this kernel could be
 part of FreeDOS 2.0. I shared his announcement on the website and on
 freedos-devel this morning.



 I think that brings us to this discussion. :-)


 *My thoughts on FreeDOS 1.2 and FreeDOS 2.0:*

 I think the next distribution will be

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

2015-01-01 Thread Aitor Santamaría

Hello!

Notes below.
BTW, Whatever happened to Japheth's pages?? Is server down?  (see JEMM's
LSM for URL's).

Aitor


2015-01-01 19:31 GMT+01:00 Mercury Thirteen mercury0x0...@gmail.com:

 1 - I like the idea of being able to run apps for multiple other OSes, but
 I think that ability should fall to a program running atop FreeDOS, not to
 the FreeDOS kernel itself. That would be a very cool feature, but the
 amount of code needed to add it to the kernel would probably be too large
 for us to continue to be viable in the tiny memory space market. FreeDOS
 should do one thing (be as DOS-like as possible, not only in its interface,
 but in its memory footprint) and do it very, very well. It would be better
 to make individual apps to serve as emulators for foreign apps than to have
 this feature build in. And I guess, in a way, these emulators which run
 atop FreeDOS to support PE EXEs, DLLs and console Windows apps would serve
 as the VXD-like drivers which you specify, so my point may be moot here -
 maybe we're both speaking about the same things, only using different
 words. lol


I don't want to give the impression that the main idea is to run other
kinds of executables. It is a nice addition, but my main interest is to run
DOS itself, and DOS applications, maintaining 100% compatibility.

The most wonderful stuff that could be done, in my opinion, goes along the
experiment that Schulman does in Unauthorized Windows95, and that I'd
love to see somehow some day. IIRC:
- he wrote an example DOS program that requests memory via XMS. For me, XMS
(or a XMS manager) is as much a part of DOS as is, say, the redirector.
- he renamed KRNL386.EXE (the main Windows executable) to something else,
and copied COMMAND.COM into KRNL386.EXE
- then he ran WIN /3, the program that runs the extender (VMM32.VXD) and
then uses  KRNL386.EXE as shell, this is, COMMAND.
- he entered on a magic world of having pure MS-DOS inside a VMM.
Everything ran as MS-DOS does, but when he ran the example program, he
could allocate more XMS than the existing physical memory, and all that
because the underlying VMM32.VXD+VSD's were doing the virtual memory magic.

Pure MS-DOS, inside the most DOS-compatible VMM implementation that one can
get. The book also mentions that in some Windows versions, the extender was
called  DOS386.EXE, instead of VMM32.VXD, quite meaningful. In my opinion,
DOS386.EXE is more an MS-DOS piece than a MS-Windows piece: Windows was
merely a fancy (and complex) GUI DOS application ran on top of DOS386,
that was also coded to run on top of NTOSKRNL.

One of the (IMHO) brightest (and latest) additions from Microsoft to
MS-DOS, that I suppose that was coded after EMM386.EXE.

2 - I'd say including Linux - or any other OS, for that matter - makes this
 project pointless. We should make FreeDOS its own standalone OS, not
 dependent on any other package, emulator or OS. This will give our users
 the best possible experience and greatly simplify development and debugging
 because we control all our own code. As you point out, we'd lose some (a
 lot?) of the DOS flavor in going this route.


I don't see it as you do. First, I guess many FreeDOS users actually use it
on DOSEmu, or any other VMs, less on bare metal. It is the same FreeDOS in
both cases, and it has always been out of the scope of FreeDOS project:
in the latter case, FreeDOS relies on BIOS manufacturers. In the former, I
simply mean to outsource it to the Linux project ;)  You never care how
to deal with multiple drivers in a 32/64 bit world: as long as DOSEmu
translates the Linux stuff into BIOS-compatible stuff, we are safe ;)

3 - While it would be great to be able to make a DOS from scratch based on
 modern technology, I fear we'd lose too much in the way of compatibility
 this way, and we don't want to do that. Just think of the possibilities,
 though... :) lol

 I think I agree with you on point number one. That seems to correlate with
 my thoughts as the best (e.g. most compatible, flexible and powerful) way
 to go.


What I dislike of the third approach, is that sooner or later, you will
have to standarise and tell how to write drivers for such a FreeDOS-32
project. The option (1) says: don't make it up, just write good old VxD's.

I don't know the internals of FreeDOS-32, but maybe (1) and (3) are not
exclusive from each other: I seem to remember that at some point, the
FreeDOS-32 guys did a 32-bit FAT driver. Perhaps that could be turned into
VFAT/VREDIR...

Cheers,
Aitor
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___

Re: [Freedos-devel] KEYB BUG

Thank you Tom!!

I've set this bug to my list of to-do's, and will go to the next version.

Aitor


2012-06-25 13:24 GMT+02:00 Tom Ehlert t...@drivesnapshot.de:


 KEYB.EXE 11,446 06-24-12

  leaves, when running, a huge memory hole. at least with only HIMEM
  loaded. note the HUGE memory hole behind KEYB

 the problem is

 function MCBAlloc ( para: word ) : word;
 var allocs,f,m: word;

 mov ah, $58  { set alloc strategy }
 mov al, 1
 xor bh,bh
  mov bl, $41
 int $21

 using 'best fit' is virtually ALWAYS a bug for a TSR

 solution 1) use some buffer in the program, at the end of the TSR
 code. use/resize this buffer as needed

 solution 2) use
   mov bl, $82   last fit, try high then low memory

 this allocates memory from top, but doesn't create holes.

 unfortunately I'm not able to compile this; awaiting the  maintainer
 to fix this bug

 Tom



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

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] KEYB BUG

Hi,

The problem is that I'm not having as much spare time lately as I used to
have.
At this moment, I'm trying to recover a comfortable programming environment
in a Win7 Laptop.

But it's not so easy as it used to be since the 64-bit arrived everywhere,
the 16-bit DOS programs no longer run natively, and I'm setting a virtual
machine with a network link to my real harddrive. If only things were as
easy as they used to be :(

There's another idea lingering around (but that I won't be able to perform
in a time soon), which is to create a virtual machine with DOS development
software, that could maybe be made downloadable for whoever wants to
develop for DOS. The problem here is picking the operating system that can
route such network drive correctly, and on which you can comfortably
multitask between the IDE, compiler, and a DOS to run tests (out of
licensing problems, WinXP would be a nice choice :( ).

Choosing the VM for a freely distributable manager is also a problem: in a
remote past I used VMware, that worked fairly well. I have been
experimenting with Bosch, QEmu, and VirtualBox, as I also wanted Linux VMs
for such environments, and I was pretty unsuccessful with Bosch, somewhat
successful with QEmu, but VirtualBox seemed to be doing pretty well.

What's your own experience for virtual machines? ideas or suggestions?

Aitor




2012-08-11 10:06 GMT+02:00 Rugxulo rugx...@gmail.com:

 Hi again,

 On Mon, Jun 25, 2012 at 10:11 AM, Tom Ehlert t...@drivesnapshot.de wrote:
 
  Surely a simple binary patch is possible in the meantime. I've not
  tested this (yet), but you could try this:
 
  upx -d keyb.exe
  hiew keyb.exe (or similar hex editor)
  offset 0x3E06 is mov bl, 0x41
  change offset 0x3E07 from 0x41 to 0x82
  run modified version for comparison (keyb.exe /blah ...)
 
  ok. this works much better.
  now when will we have FreeDOS 1.1.2 with this bug fixed ?

 Unless somebody else volunteers, it's probably? up to Bernd (no
 pressure!), so when it's done!   ;-)

 BTW, it's been almost two months since you first mentioned this, so I
 don't know what's up with Aitor, haven't heard from him. It's easy
 (maybe too easy!) to forget little fixes when no one shows much
 interest. I can only blindly guess that Aitor only has intermittent
 access to the Internet these days. Oh well, blame real life (tm), this
 isn't hugely urgent or important anyways.

 Anyways, I figured I'd go ahead and upload this patch (and the FD Edit
 one) to iBiblio for completeness. I mean, I don't know what else to
 do, any better ideas??

 http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/2.01/
 http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/edit/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] KEYB BUG

Hello,


2012-08-12 16:32 GMT+02:00 Rugxulo rugx...@gmail.com:

 FD EDIT doesn't seem to compile in TC20 anymore. Though it worked fine
 for me with TC++101, but that's not freeware from Embarcadero anymore.
 It may? (or at least used to) optionally compile with OpenWatcom, but
 I haven't personally tried yet. (Seems Aitor's build internally says
 Borland C++ from 1991 while my TC++101 says Turbo C++ from 1990.
 In other words, an XDelta is almost as big as the new .EXE itself due
 to differing compilers, so that's a bust.)


Apparently TC2 and TC++ were rather incompatible, so I opted for TC++, but
the compiler of preference is OpenWatcom ;)

Some of the base functions to interact with DOS (just calling DOS functions
that OpenWatcom libraries don't carry, such as country info, mouse, ...)
have even been thinking of rewriting in OpenWatcom style, maybe at some
point I could contribute then to OpenWatcom, if I happen to discover how
(similar sources come with a comment that they have been automatically
created, so I have to figure out how OWC works).



 FD KEYB uses TP7, which ain't freeware, so we're kinda stuck there.
 Luckily, it's only a one-byte patch (thanks to Tom E.), very easy to
 apply.

 You could legitimately complain and say new developers should use
 free/libre tools, but most of this code is legacy, and people are very
 strongly attached (often with good reason) to their old tools (often
 with no modern counterpart). Kinda unavoidable, I guess, so I don't
 want to suggest anything drastic.

 I don't know. Honestly, I almost hate to upload a patched binary of
 these in lieu of the official maintainer, but source patches are okay.
 But hey, if we have no other easy choice, I'll do it. (Advice
 welcome.)

 Well in this case, it wasn't a question of choice. To have KEYB faster at
first stage, I borrowed some from xKEYB, although KEYB is nowadays
basically pretty new. The resident code (and part of the transient code) is
pure assembler, and my idea was at some point to take it out to TASM (sigh!
maybe later to NASM or even to C) code that could be eventually linked to a
C transient area that could be compiled with an open source compiler. But
it is a big change. I started working on this without dropping TP7 on a
first stage, but the handling of the Segment registers is tricky, and
didn't put much time on it.

Another idea could be to try and port (as conditional compiles or as fork
KEYB3) the functionality to mKEYB and have it 100% in C: after all, you
just need to make it aware of the KeybCB's (the big part), and some other
minor functionalities:
- the int9x handler for pre-AT machines (is it worth?)
- override decimal character to layout
- int2f hook to be called by DISPLAY
- using it to just unhook/unload a previously loaded instance
- the safe mode for preventing keyb bombs...
...

Aitor
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] KEYB BUG

Hi Geraldo,

Not that much of a problem of licenses for myself, but for creating a
distributable developer machine :)

Thanks anyway!
Aitor



2014-03-01 2:07 GMT+01:00 Geraldo Netto geraldone...@gmail.com:

 Hi!

 Yep, you're right, vmware/virtualbox have a pretty much out-of-box setup
 But i do really enjoy qemu :)

 BTW, dunno if it helps but i have a licensed version of windows 98
 just the original manual with the serial number, lost the cd
 I can send it to you

 Also, for windows xp, maybe you could try the reactos
 http://www.reactos.org/
 an opensource implementation of windows based on wine


 See Ya!

 Geraldo Netto
 Sapere Aude = Non dvcor, dvco
 São Paulo, Brasil, -3gmt
 site: http://exdev.sf.net/


 On 28 February 2014 21:40, Aitor Santamaría aitor...@gmail.com wrote:
  Hi,
 
  The problem is that I'm not having as much spare time lately as I used to
  have.
  At this moment, I'm trying to recover a comfortable programming
 environment
  in a Win7 Laptop.
 
  But it's not so easy as it used to be since the 64-bit arrived
 everywhere,
  the 16-bit DOS programs no longer run natively, and I'm setting a virtual
  machine with a network link to my real harddrive. If only things were as
  easy as they used to be :(
 
  There's another idea lingering around (but that I won't be able to
 perform
  in a time soon), which is to create a virtual machine with DOS
 development
  software, that could maybe be made downloadable for whoever wants to
 develop
  for DOS. The problem here is picking the operating system that can route
  such network drive correctly, and on which you can comfortably multitask
  between the IDE, compiler, and a DOS to run tests (out of licensing
  problems, WinXP would be a nice choice :( ).
 
  Choosing the VM for a freely distributable manager is also a problem: in
 a
  remote past I used VMware, that worked fairly well. I have been
  experimenting with Bosch, QEmu, and VirtualBox, as I also wanted Linux
 VMs
  for such environments, and I was pretty unsuccessful with Bosch, somewhat
  successful with QEmu, but VirtualBox seemed to be doing pretty well.
 
  What's your own experience for virtual machines? ideas or suggestions?
 
  Aitor
 
 
 
 
  2012-08-11 10:06 GMT+02:00 Rugxulo rugx...@gmail.com:
 
  Hi again,
 
  On Mon, Jun 25, 2012 at 10:11 AM, Tom Ehlert t...@drivesnapshot.de
 wrote:
  
   Surely a simple binary patch is possible in the meantime. I've not
   tested this (yet), but you could try this:
  
   upx -d keyb.exe
   hiew keyb.exe (or similar hex editor)
   offset 0x3E06 is mov bl, 0x41
   change offset 0x3E07 from 0x41 to 0x82
   run modified version for comparison (keyb.exe /blah ...)
  
   ok. this works much better.
   now when will we have FreeDOS 1.1.2 with this bug fixed ?
 
  Unless somebody else volunteers, it's probably? up to Bernd (no
  pressure!), so when it's done!   ;-)
 
  BTW, it's been almost two months since you first mentioned this, so I
  don't know what's up with Aitor, haven't heard from him. It's easy
  (maybe too easy!) to forget little fixes when no one shows much
  interest. I can only blindly guess that Aitor only has intermittent
  access to the Internet these days. Oh well, blame real life (tm), this
  isn't hugely urgent or important anyways.
 
  Anyways, I figured I'd go ahead and upload this patch (and the FD Edit
  one) to iBiblio for completeness. I mean, I don't know what else to
  do, any better ideas??
 
  http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/2.01/
  http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/edit/
 
 
 
 
 --
  Flow-based real-time traffic analytics software. Cisco certified tool.
  Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
  Customize your own dashboards, set traffic alerts and generate reports.
  Network behavioral analysis  security monitoring. All-in-one tool.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
  ___
  Freedos-devel mailing list
  Freedos-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/freedos-devel
 


 --
 Flow-based real-time traffic analytics software. Cisco certified tool.
 Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
 Customize your own dashboards, set traffic alerts and generate reports.
 Network behavioral analysis  security monitoring. All-in-one tool.

 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Flow-based real-time traffic analytics software. Cisco certified tool

Re: [Freedos-devel] GARBO dead?

2013-12-28 Thread Aitor Santamaría

Thanks Rugxulo!

Seems that the breakage was mirrored too? :(

Aitor


2013/12/27 Rugxulo rugx...@gmail.com

 Hi, long time no see!   :-)

 On Thu, Dec 26, 2013 at 4:55 PM, Aitor Santamaría aitor...@gmail.com
 wrote:
 
  I don't know if you realised, but the GARBO files at University of Waasa
  seems dead?
 
  http://lipas.uwasa.fi/~ts/garbo.html

 
 An important note: The workstation hosting Garbo at the University of
 Vaasa, Finland, has broken down in 2012. This is final. The
 university's ICT Management informs that the broken workstation will
 not be replaced. Thus the Garbo library has ceased to exist. The
 relevant copyrights, however, are not released.
 

  It was a nice repository of, at times, useful stuff, does anyone know if
 it
  had been mirrored somewhere else before it died?

 According to Arjay's 16.02.2013 post on BTTR, there is a mirror here:

 https://archive.org/details/2012.11.24.ftp-garbo-mirror


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

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

[Freedos-devel] GARBO dead?

2013-12-26 Thread Aitor Santamaría

Hello,

I don't know if you realised, but the GARBO files at University of Waasa
seems dead?

http://lipas.uwasa.fi/~ts/garbo.HTML

It was a nice repository of, at times, useful stuff, does anyone know if it
had been mirrored somewhere else before it died?

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

Re: [Freedos-devel] Freedos and lack of drivers

2011-09-18 Thread Aitor Santamaría

Hi,

2011/9/11 jhall jh...@freedos.org:

 There are multitasking DOSes (DR-DOS, RDOS, TSX-32 ??, etc.)

 inherently useless


 Not useless, really. For example, MS-DOS 5 introduced their DOS Shell that
 supported task switching, a rudimentary form of multitasking.
 I used to use this feature all the time as a student: for example, to run a
 word processor and spreadsheet program as separate tasks. I think I usually
 had a command.com shell in there too. That let me write up my data analysis
 for labs much faster, because I could quickly jump back to the spreadsheet
 or my own analysis program to look at results, then describe it using the
 word processor.
 I'd love to see this as a feature added to FreeDOS one day.

Me too!
I fear about hardware status, thought it should be feasible for
regular programs.

Aitor

--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Freedos and lack of drivers

2011-09-18 Thread Aitor Santamaría

Hi,

2011/9/11 Bernd Blaauw bbla...@home.nl:
 Not sure about FDSHELL's abilities. I'd love for someone to come up with
 a decent DOSSHELL.INI for it, including a usable/pretty color scheme. It
 can already jump to DOS, same for EDIT

Annotated as feature request.
(regrettably, don't expect it soon).

Aitor

--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Freedos and lack of drivers

2011-09-18 Thread Aitor Santamaría

Hi,

2011/9/13 Jim Hall jh...@freedos.org:
 In DOS, it would be awesome to have true multitasking, where you can
 let a process run in the background (like a compile) while you do
 something else (browser?) But to be honest, all I really want/need is
 some sort of extension or shell that provides task-switching, rather
 than true multitasking.

There would be a way, but would require someone to find out if it is
feasible and work about it. I haven't done it myself, although I was
tempted to try out.
Pick the smallest Linux distribution that you know. Remove X and
anything about graphics. Remove any Unix stuff, and configure init to
have several virtual consoles boot the text-mode of DOSEMU (instead of
any unix-style terminal), in which you put FreeDOS.
Wouldn't it be great that you'd have several FreeDOSes running
simultaneously? (switch with Ctrl+Alt+Fn).

You wouldn't have the problem of modern hardware (Linux does the
part), but then you have quite other disadvantages (I don't know how
good would be the drive mapping process that DOSEMU does. Would be
nice if DOSEMU scanned all the disks and mapped ALL partitions
automatically).

In the meantime, yes, at least task switching would be great.

Aitor

--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] New KEYB ahead

2011-09-13 Thread Aitor Santamaría

Hi,

I have managed to patch a couple of bugs I found on KEYB 2.0, and have
KEYB 2.01 ready to launch (I just have to create the packages and
such).
I haven't been able to reproduce the bugs that some people have
occasionaly mentioned here on the list when in use with JEMM, so I
don't know if the patches I have applied improve it, but if someone
could/wants to try it and see if those bugs are gone, is more than
welcome to get the binary and test it before I do the official
release.

Cheers to all,
Aitor

--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Pat Villani

2011-09-13 Thread Aitor Santamaría

Sad news indeed!!

The first stone towards the big building called FreeDOS.

My condolences too,
Aitor

2011/8/30 Jim Hall jh...@freedos.org:
FreeDOS friends:

I must share the sad news that Pasquale Pat Villani, 57, passed away
on Saturday night, at his home. Many of you knew Pat. For our new
members: Pat Villani was the author of the original FreeDOS kernel.

Pat and I were good friends. Although we never met in person, we
chatted on the phone several times. And lots and lots of email
conversations, half the time about FreeDOS and half about just
anything. The last time Pat and I emailed each other, he was following
the work on FreeDOS 1.1 with great interest.

I have known for a long time that he wasn't doing well, but of course
you're never prepared for these things.

To read the obituary, and to leave an online condolence message,
please visit:
http://cmfh.frontrunnerpro.com/runtime/192/runtime.php?SiteId=192NavigatorId=30617op=tributeObituaryviewOpt=dpaneOnlyItemId=943473

If that direct link doesn't work, you may find the information on
http://www.claytonfuneralhome.com/

My thoughts are with his family.

Thanks.
-jh

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] confused by NLS-settings

2011-07-13 Thread Aitor Santamaría

Hello,

 This NLS stuff is doing my head in, even before trying to automate it in
 configuration scripts..

 CONFIG.SYS:
 
 COUNTRY=31,858,C:\FDOS\BIN\COUNTRY.SYS

 NLS.BAT / AUTOEXEC.BAT:
 =
 NLSFUNC C:\FDOS\BIN\COUNTRY.SYS
 DISPLAY CON=(EGA,858,1)
 MODE CON CP PREP=((858) C:\FDOS\CPI\EGA.CPX)
 MODE CON CP SEL=858
 KEYB US,858,C:\FDOS\BIN\KEYBOARD.SYS /NOHI
 CHCP 858


 1) Is above correct? If not, how should it be?

MODE CON CP SEL=858
is redundant with
CHCP 858.

The correct one in this case is CHCP, which changes the codepage
globally (MODE CON CP SEL would only change it for the CONSOLE).

 2) Why's KEYB 2.0 crashing under JEMMEX? (see below #1)
 3) Why's KEYB 2.0 crashing when clean booting? (see below #2)

I captured a couple of bugs within KEYB 2.0 final, but my question is:
 why are you using the Pre4, instead of the 2.0 FINAL?
I am a bit pressed for time this week, then will be off till august.
If I happen to find time for the 2.01 release, I'll let you know, to
see if it works better for you.

 4) Why's NLSFUNC 0.4 not throwing errorlevel 1 or so when already installed?

This one I don't know (I don't know its implementation details)

 5) DISPLAY seems to be able to be loaded lots of time in a row?

You mean that you can load it twice?
In theory, you could load it to work with different hardware. In
practice, you never have (e.g.) an VGA card and an EGA card at the
same time.
If that bothers you, use /C.

 6) Why's CHCP choking? Expected it to work in 2040 as I think it worked
 in 2035 or 2037 or even 2039. Might be due to one of earlier loaded
 tools (be it NLSFUNC, DISPLAY or MODE) ?

I don't know. Unfortunately, due to DISPLAY being a TSR, both MODE and
NLSFUNC should be tuned with it. If the NLSFUNC version you are using
is not liked by DISPLAY, then you can replace CHCP with MODE CON CP
SELECT, which is not very good, because kernel will not know about the
codepage change (and you could have problems with turning filenames
into the uppercase, and storing them in FAT).

 7) Isn't CHCP supposed to be replacing MODE CON CP SEL ?

Yes. Even doing MORE than MODE CON CP SEL. It would be the replacement for

MODE any_driver CP SEL
MODE kernel CP SEL

;)

 8) How do I get an euro sign from keyboard? Thought using 858 instead of
 850 would allow this, keyboard has a sign above the 5.

I don't know, but Henrique may be able to tell me (or find out by
watching US.KEY in the sources from the layout packs).

 9) I think Rugxulo mentioned something about KEYB/KEYBOARD.SYS in some
 earlier mail?

¿?

Aitor

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on Lean Startup 
Secrets Revealed. This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] confused by NLS-settings

2011-07-13 Thread Aitor Santamaría

Ok, that's on me. I found 2-3 bugs that I have already patched
(almost), I just have to test a bit, then pack it all.
If I don't happen to find time to do it fully, I may distribute two
files (the source and binary) to some people, in case it works better
for you and it is required for 1.1 in the next days and someone can do
me the favour (the rest shouldn't change, maybe the readme and such).

Aitor

2011/7/13 Bernd Blaauw bbla...@home.nl:
 Op 13-7-2011 23:37, Bernd Blaauw schreef:
 hm am I confusing DISPLAY and KEYB once again?..oh well, nevermind my
 previous mail thus.

 Time to end my monologue: updating KEYB to 2.00-final, same issues apply
 (under kernel 2040).

 --
 AppSumo Presents a FREE Video for the SourceForge Community by Eric
 Ries, the creator of the Lean Startup Methodology on Lean Startup
 Secrets Revealed. This video shows you how to validate your ideas,
 optimize your ideas and identify your business strategy.
 http://p.sf.net/sfu/appsumosfdev2dev
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on Lean Startup 
Secrets Revealed. This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] confused by NLS-settings

Hi Bernd,

Briefly in DOS, both kernel and character device drivers are (or
should be) codepage aware.
- Kernel because of the collation tables, used for example to turn
filenames into the uppercase, and so store them uppercased in the FAT
- Character devices, because sending out a character to a character
device should be codepage independent. Thus, each character device
should know how to write certain byte of certain codepage. This all
is controlled using character device's IOCTL call

This all is broadly not used in the US, thus it is mostly loadable,
in the sense that it isn't loaded by default kernel and character
devices, and should be loaded as extensions.

Finally, a kernel interrupt  controls the codepage change (21h/6602h)
in the system as a whole: changes the collation table and the
character devices (issuing IOCTL's) globally.


2011/6/29 Bernd Blaauw bbla...@home.nl:
 This involves the following:
 * COUNTRY= (config.sys, COUNTRY.SYS / COUNTRY2.SYS / COUNTRY3.SYS)
Set the initial collation table (data is retrieved from the specified file)

 * DISPLAY (a TSR by Aitor, versus device driver in MSDOS)
CON extension:   should control both keyboard and screen. To change
screen's codepage, uses int9h. To change keyboard's codepage, calls
KEYB (int 2Fh / AD81h)
DISPLAY itself has a int 2Fh / AD00h backdoor, that can do all the IOCTL stuff:
- MS-DISPLAY is a regular DOS device driver that overrides system CON
 (provides IOCTL to DOS' CON device)
- FD-DISPLAY is a TSR, implements only the 2Fh / AD00h backdoor

 * NLSFUNC (with optional COUNTRY support, but only if not listed in
 config.sys yet?)

Implements the logic behind 21h/6602h  to change the codepage globally.

 * MODE versus MODECON versus different configurations whether or not
 COUNTRY= is set?

MODE CON CP
or
MODE xxx CP
is the DOS standard way to call IOCTL on the device xxx. Thus, could
be used to change the codepage of the device xxx, but also for some
other codepage aware functionality, such as loading codepage tables,
etc. As FreeDOS DISPLAY is not a true device driver, for CON it must
issue the 2Fh / AD00h backdoor, and thus MODECON was created. This
functionality was included into FD MODE, thus MODECON is deprecated
and must no longer be used.

MODE xxx CP PREPARE
is the way to load a codepage from certain  CPI/CPX file  (using IOCTL
write from device xxx, or int 2Fh / AD00h for FD-DISPLAY)

MODE xxx CP SELECT
is the not recommended way to change the codepage for device xxx
(using generic IOCTL from device xxx, or int 2Fh / AD00h for
FD-DISPLAY).
It leaves the system inconsistent: codepage should be changed for
kernel and ALL the devices at the same time (21h/6602h), in other
words, CHCP.

 * CHCP (internal command to FreeCOM)

A simple call to 21h/6602h.

 * KEYB (and CPI/CPX files)
The keyboard part of the CON extension. It really makes BIOS be
codepage aware on keyboards.

You miss PRINTER.SYS (if we had any), which would be the PRN extension.
I haven't ever seen extensions to COMx devices, but I guess they
should be (if they exist) device-dependent.

 * EDIT 0.9a prints its version and DFLAT banner at every invocation.
in the background. If it causes problems, I have annotated to create a
switch to turn it off.

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

Re: [Freedos-devel] confused by NLS-settings

Hello,

2011/6/29 Bernd Blaauw bbla...@home.nl:
 I remember DISPLAY 2.0 being troublesome with regard to UMBs, but that
 was years ago.

It is not that it is trobulesome with regards to UMBs, but that you
hardly ever have so much room in UMBs to load it.
DISPLAY allows you to have a maximum of 5 codepages prepared in memory
to be changed, and that is a bit less than 64 KB. After loading, in
the commandline you usually only make room for 1 or 2 codepages (last
parameter):

DISPLAY CON=(EGA,437,1)

and you barely use 11KB, but you don't know beforehard, thus DOS needs
to reserve the whole of 64 KB just in case.

Most modern versions use XMS and take lesser convenctional memory.

 Isn't MODECON deprecated / unnecessary??
 Guess so, but that's what my entire help request is about.

Confirmed. Eric introduced MODECON into MODE some versions ago.

 Did I mention hating CuteMouse 2.1b4's cursor/pointer refreshing speed
 in EDIT ? Like 5 times per second instead of once every 2 seconds or so :(

There's a similar bug filled into EDIT that I marked as not
reproduced, because I was never able to reproduce it, but I never
tried CTMOUSE now that you mention it.
So in the end it may end up being a CTMOUSE bug (or misconfiguration)?

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

Re: [Freedos-devel] confused by NLS-settings

Hello,

2011/6/30 Rugxulo rugx...@gmail.com:
 I remember DISPLAY 2.0 being troublesome with regard to UMBs, but that
 was years ago.

 It still needs a lot of unnecessary UMB room free to load there, e.g.
 64 kb or some fairly high amount. And you may even have to explicitly
 mention it. I forget exactly and always (I think) loaded it low. Well,
 I'd have to check 

If only I could assume that there's ALWAYS XMS ;)))

Ok, I'm revealing something about the next version (if I happen to
find some spare time for it): There'll be a DISPLAYX.COM file that
will refuse to load if there's no XMS. But if there is, then the
maximally needed RAM will be of about 10-11 KB, thus the UMB trouble
is gone.

Could it be made even smaller? I have ideas to do so, but not so much
motivation:
- if I can asume everyone has a VGA card and stays in text mode
- if I can asume that (J)EMM386 has the ROM= option implemented
- ...

 NLSFUNC seems to be able to take COUNTRY.SYS file as an argument/parameter

 Yes, but it's hardcoded to a specific DISPLAY version, I think. Like I
 said, I never heavily used it (COUNTRY + NLSFUNC) since it lacked
 support for 853 anyways.

Yes. The payload for being DISPLAY a TSR and not a device driver is
that MODE and NLSFUNC are FD-DISPLAY specific (and tied to versions
whenever int 2FH changed).
I intended to turn it into a device driver once it is stable, but I
don't really know if people prefer a TSR or device driver.

 * EDIT 0.9a prints its version and DFLAT banner at every invocation.
 Recompile?  :-)   Or just include a different editor (I'd cram TDE, if
 possible, or EZEDIT if not).
 Pretty stuck at using EDIT as a baseline replacement of MS EDIT. Other
 programs always welcome as extension.

 Well, the 64 kb file limit was a bit of a put-off for me, personally.
 Maybe good for average use, I guess (just not my favorite preference).

If only I could asume that there is ALWAYS a DPMI...  ;)))

Well, from the above you see how much one would need a 386+ and VGA
card as a minimum. Would be nice to know how many real FreeDOS users
do not meet any of these two requirements.

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

Re: [Freedos-devel] confused by NLS-settings