Anton Ertl <[EMAIL PROTECTED]> writes Re: [gforth] help with gForth 0.6 -- please
[..] > Better: change the definition of os-class in envos.fs. This also > fixes the dosekey.fs problem. ( I decided to react because I'm not sure it is clear what I've done, or what the pitfall with os-class is ) As far as I understand it, cygwin.dll lets gForth think it is running on unix. In that case, it would be wrong to load doskey.fs and dosekey.fs (I don't load these files (which is impossible as dosekey.fs is missing!), I only changed the [IF] in history.fs because "~/" was handled wrong). As far as I can see, the ( NT 4.0 console ) keyboard behaves like it does in Linux (i.e. ESC seqs for keypad keys): ( press left arrow ) hex key ok [D .S <1> 1B ok So I should NOT let gForth think it is running on windows, because then it loads doskey.fs, which (seems to) expect left-arrow to emit something like 0 <some number>. >> CYGWIN.dll does not perfectly emulate a unix environment. For >> that, it would have to recognize a path like "~/.gforth-history" >> and convert it to something reasonable. > Hmm, ~/.gforth-history works well enough for me (ok, now a newer > cygwin1.dll is installed on my test system than included in the zip > file, which might make a difference). <sigh> :-) > Unsurprisingly, vt100key.fs works nicely when talking to an xterm, > while doskey.fs does not work. Deciding such things by osclass is not > a good idea. When cygwin.dll is as consistent as you say it is in its current release, os-class is not needed in gForth itself. However, at some point a programmer might want to know for sure on which OS his program is running, without funny tricks. -marcel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
