[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: Ansified XyWrite (Att. R. Holmgren)
- Subject: Re: Ansified XyWrite (Att. R. Holmgren)
- From: "Robert Holmgren" holmgren@xxxxxxxx
- Date: Fri, 27 Dec 2002 16:20:38 -0500
** Reply to message from -- on Thu, 26 Dec 2002 12:39:14 +0100
Manuel:
Look, I'm sorry I was short-tempered. I just get awfully
fatigued. This morning, as an example, there were three
people privately requesting files. Well, I'm happy to
provide them, but it eats SO MUCH TIME. You have to find
the files, zip them up, and if you don't explain them
carefully, you're just inviting more questions. So when I
get an open-ended query like your's, about an old issue...
which I've mostly forgotten... I occasionally go ballistic.
(Time, perhaps, to take a long leave-of-absence.)
> If I erase startup.int and continue attempting to load
> ansiup.int, I receive an error message: startup.int
> not found. Solution: to include a line in my .bat
> file, copying ansiup.int as startup.intbefore running
> editor.exe. Then, ANSI keyboard, printer files, etc. were
> loaded. Apparently, XyWrite refuses to load an alternate
> startup file against the information included in the
> Manual (pages 2-33 and 2-34).
Try this, it works for me:
EDITOR.EXE ,d:\path\ANSIUP.INT /e4000
Then double-check to see which INiTialization file actually
ran, using VA/NV $ST (it will be ANSIUP.INT,
guaranteed).
A separate thing to do is to shell to DOS (DOS/NV), and run
MEM /C |MORE
and see whether EMS memory is actually being set aside for
your session. If you have a fairly new machine, it may be
that there is no possibility of EMS being available, in
which case you can just forget about the /E4000 thing. (I
need to look more deeply into what memory areas need to be
excluded in order to set aside EMS memory in a Win32 VDM --
I think USB peripherals, for example, try to grab the DOS
upper memory area that would normally be used by EMS, but
that's just a guess -- the problem is, I truly detest
Windows, and resist firing it up solely to determine answers
to these kinds of questions -- keep hoping somebody else
will just know and volunteer the solution...)
> If, with the right files loaded, I shell to DOS, CHCP 1252
> is not enough to get an ANSI display in full screen mode
> (and after running CHCP 1252 in DOS session, 1252 code
> page is the active one, without any doubt). Default
> XyWrite codepage is 850 after and before shelling to DOS.
You seem to be saying that you cannot get 1252 to work full
screen *except* by using CP1252.FNT -- correct? Hmmm. You
were running W98 at the time (last summer), so perhaps we
never investigated full-screen ANSI very much. I am quite
surprised to re-read it, but my own U2 Help frame for Ansi
(written four months ago) suggests that the only way I knew
to get full screen ANSI in WinNT was via CP1252.FNT. So...
I guess I'm confused because CHCP works fine in OS/2
fullscreen, & I do most of my testing in OS/2. (It's
idiotic to prevent users from running any code page they
want, but Windows does that sort of thing.)
> In windowed mode, CHCP works perfectly, together with
> the Siebert's ANSI font or lucida console fonts (not
> with bitmap windows fonts).
Correct: only TrueType [Lucida -- a Unicode font, I think]
will work, not bitmapped [raster] fonts *unless* they are
bitmapped for 1252 [the special Sieber ANSI fonts]. Quote
Microsoft:
Only the original equipment manufacturer (OEM) code page
installed with Windows XP appears correctly in a command
prompt window that uses Raster fonts. Other code pages
appear correctly in full-screen mode or command prompt
windows that use TrueType fonts.
"Other code pages appear correctly in full-screen mode" --
that's what I remember from last summer! 1252 worked
correctly in full-screen -- or at least I think it did. But
now I can't make it work. What have I forgotten? This is a
good example of why we should pursue a single problem until
it's solved; I can't recall 90% of what we did.
> If I suppress DF LA=850 or replace it with DF LA=437,
> I receive the following message: "Customization file
> contains an unrecognized command" (I think this is
> related to my U2 file, that requires 850 codepage).
Maybe, maybe not. U2 has encoded at the top, which
should override (gracefully) any system DeFault. Maybe
Spanish Windows doesn't recognize CP 437? More likely,
though, is that there's an actual error in your DFL file.
So, pulling it all together: what aspect of "ANSIfied
XyWrite" is still unsatisfactory? It works very well for
me.
-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------