Hello Don,
> Jerome, this is not an installer issue, it occurs following an otherwise
> successful install and reboot. I think it is a DOSLFN/Memory Management/SHELL
> issue. It's a bug that has been around for a long time and the only way I
> have gotten rid of it is to forgo DOSLFN.
>
> On
Jerome, this is not an installer issue, it occurs following an otherwise
successful install and reboot. I think it is a DOSLFN/Memory
Management/SHELL issue. It's a bug that has been around for a long time and
the only way I have gotten rid of it is to forgo DOSLFN.
On another note, I am in need o
Hello Don
> On Mar 8, 2016, at 1:17 PM, Don Flowers wrote:
>
> Just did an install on my multiple Hard drive/multiple DOS/FreeDOS DC5700. I
> used the advanced option and have nothing bad to report (except that *#$%
> "Error reading from drive A: DOS area drive not ready Abort Ignore Retry
>
And if you are the Bret Johnson of http://bretjohnson.us/ then I'm sure
you do have the skills!
On 3/8/2016 2:08 PM, John Hupp wrote:
> @ Bret: Perhaps you have the skills to offer a fix for EDIT, or can
> convince the current developers to do so!
--
The default FreeDOS 1.1 installation does not load KEYB for a US
keyboard (nor do I have it loaded). CHCP reports Code Page 858, as
expected. And as I reported in my original post on this topic:
- Even in Edit, R-Alt acts like L-Alt with no document open.
- In SetEdit, R-Alt acts like L-Alt.
-
It is known that the R-Alt (AltGr) works differently than L-Alt with some
keyboard layouts, but when it is a US keyboard layout (and some other layouts
as well) that is not the case. This is a bug and it should be fixed.
There are DOS functions that EDIT can call to tell what kind of keyboard l
Hi,
On Mon, Mar 7, 2016 at 5:34 AM, Rafael Angel Campos Vargas
wrote:
>
> Annual inform:
>
> First, thanks to FreeDos team for the link where you will encounter previous
> versions of FreeRay.
> I thanks you a lot.
>
> This year package FreeRay2015 includes sixteen new 3D objects LGPL with HTML
Just did an install on my multiple Hard drive/multiple DOS/FreeDOS DC5700.
I used the advanced option and have nothing bad to report (except that *#$%
"Error reading from drive A: DOS area drive not ready Abort Ignore Retry
Fail?" on mulitple file copy. Tried adding \ to destination directory to no
I use setedit almost exclusively and R-Alt is working correctly with an
open file.
On Tue, Mar 8, 2016 at 11:48 AM, John Hupp wrote:
> I have argued much the same, but I have a recollection that the EDIT
> behavior is by design, with R-Alt (aka AltGr) functioning as a dead key
> to provide suppo
I have argued much the same, but I have a recollection that the EDIT
behavior is by design, with R-Alt (aka AltGr) functioning as a dead key
to provide support for the Euro character, etc.
There is an old, unattended bug report on the issue, though it may need
rounding out, and in any case some
With a US keyboard layout, R-Alt and L-Alt are supposed to work exactly the
same way in the vast majority of programs, including EDIT.
I did a couple of experiments, and in FD-EDIT it doesn't work that way. It's a
bug in the way the program is written. MS-EDIT works just fine. I haven't
look
11 matches
Mail list logo
