Win32Forth command-line apps
Ed
command-line apps to Windows.
Win32Forth 6.13 looks like the best bet since it can be
TURNKEY'd and the resulting exec reasonably small.
The problem is the console handling.
I'd prefer the Win app to mimic the original DOS
command-line behaviour i.e. when the turnkey is run from
a DOS box it doesn't initiate a new window and when it
terminates any messages the program has output is left
on the DOS box screen - ready for the user to read and
re-run the program if need be.
What I think I need is KEY EMIT etc redirected to basic
stdin/out a la C. Is that possible, has anyone done it?
Thanks.
ron
> I've had a request to port one of my 16-bit MS-DOS
> command-line apps to Windows.
>
> Win32Forth 6.13 looks like the best bet since it can be
> TURNKEY'd and the resulting exec reasonably small.
> What I think I need is KEY EMIT etc redirected to basic
> stdin/out a la C. Is that possible, has anyone done it?
If I may suggest my own Reva Forth (http://ronware.org/reva), which
produces very small turnkey apps, and also with minimal effort
produces Linux, Mac OS/X and Windows (command-line) executables. It
is also free. The only catch is it is not ANS-compliant, which may or
may not be an issue for you.
Best regards,
Ron
George Hubert
Look at the words D_KEY D_EMIT etc. in the Win32Forth
kernel. They're designed for a console that is allocated
rather than a DOS box but should be useable with one.
You may need to add words for cursor positioning if
your app needs it.
George Hubert
Stephen Pelc
>I've had a request to port one of my 16-bit MS-DOS
>command-line apps to Windows.
>
>Win32Forth 6.13 looks like the best bet since it can be
>TURNKEY'd and the resulting exec reasonably small.
>
>The problem is the console handling.
>
>I'd prefer the Win app to mimic the original DOS
>command-line behaviour i.e. when the turnkey is run from
>a DOS box it doesn't initiate a new window and when it
>terminates any messages the program has output is left
>on the DOS box screen - ready for the user to read and
>re-run the program if need be.
VFX Forth for Windows does this if saved as a console app:
saveconsole vfxconsole
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Ed
Thanks, Ron. I do have a copy of Reva, however starting with
a new and unfamiliar forth would just add to my conversion
burdens.
I've since found Win32F can be made to work as a console app
but I'll need to write words for KEY? and KEY that mimic mine.
I've been researching sources (including Reva's) on how to do
that. So far what I've found has been a little too raw e.g. they
respond to Ctrl Alt or Shift single key presses.
Ed
Thanks, I'll check it out.
As often happens I'd Googled without luck and posted out of
desperation. Later I found a reply Alex gave on c.l.f. earlier this
year when someone asked a similar question. For the benefit of
future googlers, I'll repeat the relevant part of his response here:
--
From: Alex McDonald
Newsgroups: comp.lang.forth
Subject: Re: Forth stdin and stdout
Date: Wed, 14 Jan 2009 23:24:34 -0800 (PST)
Organization: http://groups.google.com
...
To utilise stdin and stdout in Win32Forth is not trivial, as it is
designed as a Windows GUI program, not a DOS or command line program.
The win32for.exe file can be recompiled as such, but this is not done
as standard, and the feature is only available on version 6 systems.
To build a DOS version, run win32for.exe as normal and run the
following;
also vimage
cui to exetype
fsave w32fdos.exe
bye
This will create an executable called w32fdos.exe, which you can run
as usual. It will open a DOS console and a window. To create the
handles to the console;
s" CONOUT$" w/o create-file drop to stdout
s" CONIN$" r/o create-file drop to stdin
Now you can use stdin and stdout as usual with read-file and write-
file, or use redirects and pipes from the command line.
...
--
I did that and found turnkeyed apps saved by w32fdos.exe look
and feel like regular MS-DOS command-line apps.
What's needed now are suitable replacements for EMIT KEY and
KEY? It's becoming clear KEY and KEY? are going to have to
written using Window API console function calls. As these calls
return raw key events, I'm not relishing the challenge.
--
BTW there is a slight problem using Alex's w32fdos.exe. When
it boots I find it hangs until one presses Enter a couple of times.
After which it displays the message:
"On Function: CloseClipboard Windows Returned Error: 127
The specified procedure could not be found."
I can still load and turnkey my app but it would be nice if this error
problem/message could be eliminated. Perhaps the Win32F
developers might care to look into it.
p.s. It's been a very long time since there's been an official
Win32F release.
ron
> Thanks, Ron. I do have a copy of Reva, however starting with
> a new and unfamiliar forth would just add to my conversion
> burdens.
Certainly understandable :)
> I'll need to write words for KEY? and KEY that mimic mine.
What do yours do that is special?
Ed
Nothing special - but there will be fewer issues porting programs
if I make the Windows versions of KEY and KEY? behave the
same as for the 16-bit DOS forth e.g. ensure the special keys
produce the same codes.
Ed
I found D_KEY D_EMIT etc don't exist in the last official
release but only at the Win32Forth CVS developer files at
Sourceforge. I d/loaded the latest fkernel.f which should
help me with the console I/O words I need.
Reading the update logs of the files at Sourceforge has piqued
my interest. Is there a zipped snapshot of the Win32F source
files available for d/load anywhere?
Rugxulo
On Nov 9, 6:50 pm, "Ed" <nos...@invalid.com> wrote:
>
> I've had a request to port one of my 16-bit MS-DOS
> command-line apps to Windows.
Okay, this might be almost offtopic, but "why?" exactly?
I'm guessing it's due to 64-bit Windows being unfriendly to 16-bit.
But I hope it's nothing silly like "need LFNs" which can be used with
ease (int 21h, 7160h is a quick way) or "needs more RAM" (DPMI
supports 16-bit although I've never used it thus). *sigh* Kinda
annoying that fully-working DOS apps don't "just work" under Windows
anymore (DOSBox helps but doesn't really count).
Jos van de Ven
news:hdg2ru$3pk$1...@news-01.bur.connect.com.au...
> p.s. It's been a very long time since there's been an official Win32F
> release.
That is right, indeed too long.
> Is there a zipped snapshot of the Win32F source files available for d/load
> anywhere?'
See:
www.schneider-busch.de/dirk/forth/download/w32f61303.exe
It is quite close to the current state in the CVS.
Now it has a console that does not need a DLL for the console anymore.
Install it outside c:\Program Files when you use the Vista or W7.
c:\Forth might be a nice place.
Jos
Ed
Thanks Jos. Yes, I saw mention of the new console support which
is why I was keen to check it out.
Ed
I didn't enquire but I assume it was for future-proofing.
With each new Windows version, support for DOS has reduced
e.g. Vista won't run any graphics DOS app. As technology changes
supporting old systems becomes harder and more expensive.
One can understand MS not wanting to do that considering
the average computer user today wouldn't know the difference
between a program and a data file.
Rugxulo
On Nov 14, 10:25 am, "Ed" <nos...@invalid.com> wrote:
> Rugxulo wrote:
>
> > Okay, this might be almost offtopic, but "why?" exactly?
>
> > I'm guessing it's due to 64-bit Windows being unfriendly
> to 16-bit.
>
> I didn't enquire but I assume it was for future-proofing.
>
> With each new Windows version, support for DOS has reduced
> e.g. Vista won't run any graphics DOS app.
They changed the driver model in Vista, so it broke some stuff. In
fact, as you probably know, Vista had a lot of compatibility issues,
even with Win32 stuff. I would heavily doubt Win7 is any better as
it's based upon the same kernel (Vista = NT 6, Win7 = NT 6.1).
> As technology changes
> supporting old systems becomes harder and more expensive.
I've been told that NTVDM is "ancient". However, that still doesn't
explain the shift from "works" (XP) to "barely works" (Vista).
Something odd happened, and I don't know what or why. (Compiler
bugs??)
> One can understand MS not wanting to do that considering
> the average computer user today wouldn't know the difference
> between a program and a data file.
No, I honestly can't. I'm not going to give a big anti-MS rant as is
found everywhere else on the 'Net [EDIT: eh??? oops, heh], but I do
have issues with their attitude. Anybody who has run DOSBox or
VirtualBox knows that such things are still way too slow. V86 mode
exists for a reason, might as well use it. (Bill Gates called the 286
"braindead" for its pmode-only attitude. Hence V86 was a big
improvement, some say directly a result of MS petitioning for it. I
guess AMD didn't get the memo?)
What actually boggles my mind is that MS has always had trouble with
NTVDM. For instance, the original Quake (DOS/DJGPP) couldn't run under
NT due to bugs that MS either couldn't or refused to fix. And that was
a big-time game! If they didn't fix it for them (the Doom guys!),
something is wrong.
Then when Win2k/XP finally got prevalent, there were other bugs that
prevented DJGPP apps from working (hence DJGPP 2.03's patchlevel2).
Again, not fixed by Microsoft.
However, Win2k did actually add LFN support to DOS apps (previously
only available in Win9x), and WinXP added SB emulation. WinXP was the
only one of those to be offered to home users, and it was the
successor of WinME. Hence, they (I guess?) wanted to attract the DOS
(business?) users. And then they declared "DOS dead".
But Vista broke full-screen (even cmdline apps attempting simple VESA
identification calls) due to a new driver model. Allegedly you can
unofficially use an XP driver (if you can find one), but that disables
Aero, which some other apps need. Not good.
And here's the worst part: Win2k3. For some reason, somebody silently
added a 32 MB limit to any DPMI app without telling anyone, and
apparently nobody else noticed or cared. When Vista came out a few
years later, it still wasn't fixed. Only with SP1 (a year later) did
they add a (heavily undocumented!) registry hack, but Win2k3 doesn't
even support that, and no more SPs for Win2k3, even. What gives?? My
laptop (circa late 2007) "only" has 1 GB of RAM, and it's a 32-bit
Windows. 32 MB is 3% of my total RAM. If you think that's a reasonable
amount, then you don't do enough compiling with DJGPP. And that's
static no matter how much total RAM you have! I don't know who thought
that was a good idea. But apparently it's not worth fixing. Again.
That's (I think) worse than Win 3.0, even, which was the first to
support DPMI (0.9 only, sadly). Even DOSBox supports more total RAM,
64 MB. (But you need 1+ Ghz for "486" speeds!) Did I mention that DPMI
is almost the only way for DOS apps to access more RAM under Windows?
So you're effectively locked out.
Did I mention that MS doesn't support NTVDM under Win64? I know x86-64
doesn't support V86, but they did at one time emulate DOS apps on non-
x86 platforms. I guess I can't majorly complain there as we have
DOSBox, VirtualBox, (or DOSEMU under Linux w/ 16-bit emulation) etc.
But those are (again) not solutions provided by MS. (XP Mode doesn't
count either as home versions of Win7 aren't officially supported.
Besides, that needs an *extra* 1 GB of RAM, extra 16 GB of space, and
hardware virtualization support.)
P.S. Yeah yeah, nobody cares, I'm a loon, costs too much, blah blah
blah, Win32 API kiss kiss, DOS is old ptui yuck, .NET is the future or
use Linux, etc. Yeah, it's so much fun to throw away working software
and recompile / port everything over and over and over ....
Albert van der Horst
A Forth that is console based to start with may be easier.
wina could fit your bill. Turnkeys are very easy.
Redirection is easy. It is pretty ANSI.
Put this in a file test.frt:
"
: test (ACCEPT) EVALUATE . CR ;
"
wina -c test.frt
c:\temp>echo 1 2 + | test
3
>
>Thanks.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Ed
> In article <hdadbp$4uq$1...@news-01.bur.connect.com.au>,
> Ed <nos...@invalid.com> wrote:
> >I've had a request to port one of my 16-bit MS-DOS
> >command-line apps to Windows.
> >
> >Win32Forth 6.13 looks like the best bet since it can be
> >TURNKEY'd and the resulting exec reasonably small.
> >
> >The problem is the console handling.
> >
> >I'd prefer the Win app to mimic the original DOS
> >command-line behaviour i.e. when the turnkey is run from
> >a DOS box it doesn't initiate a new window and when it
> >terminates any messages the program has output is left
> >on the DOS box screen - ready for the user to read and
> >re-run the program if need be.
> >
> >What I think I need is KEY EMIT etc redirected to basic
> >stdin/out a la C. Is that possible, has anyone done it?
>
> A Forth that is console based to start with may be easier.
> wina could fit your bill. Turnkeys are very easy.
> Redirection is easy. It is pretty ANSI.
>
> Put this in a file test.frt:
> "
> : test (ACCEPT) EVALUATE . CR ;
> "
> wina -c test.frt
>
> c:\temp>echo 1 2 + | test
> 3
WINA is a dos/dpmi app rather than Windows.
I managed to port my program to the unofficial Win32F release
mentioned in a previous post. Luckily the app didn't required any
of the PC special keys, cursor positioning, color etc - otherwise
I'd still be scratching my head.
Albert van der Horst
People are telling me that all the time.
What they don't tell me is what they WANT to do,
that they CAN'T DO with wina.
dpmi is far less troublesome than cygwin or djgpp.
Pray tell me why "being dpmi" would prevent wina
being a good solution for what you want to do now!
I really want to know.
For example the wina manx application works as follows.
You have a directory with musical scores.
Manx is coupled to the extension .sco.
You click on a score file, it starts playing.
The difference is in the control window.
Instead of a bunch of predefined buttons, you have
a Forth interpreter available to stop,restart or
play the piece on a different instrument, playing
as single bar etc.
Ed
The port was not for me but others. Given it should be
able to run on current Windows platforms, a Win app
was the way to go.
I later found out the requester's system was Vista 64 -
which I'm told can't run any 16-bit dos or dpmi.
anymouse
>
> - Show quoted text -
Monopolism, do not fight it too loudly, 'cause they bite too!
http://www.dolphinconsultant.org/TestScript1994a.html
regards,
Rugxulo
On Nov 19, 7:16 pm, "Ed" <nos...@invalid.com> wrote:
>
> > >WINA is a dos/dpmi app rather than Windows.
>
> > People are telling me that all the time.
> > What they don't tell me is what they WANT to do,
> > that they CAN'T DO with wina.
> > dpmi is far less troublesome than cygwin or djgpp.
DJGPP v2 uses DPMI exclusively. DPMI is the only supported way to
access large amounts of RAM via a DOS app under Windows.
> > Pray tell me why "being dpmi" would prevent wina
> > being a good solution for what you want to do now!
> > I really want to know.
>
> The port was not for me but others. Given it should be
> able to run on current Windows platforms, a Win app
> was the way to go.
Not really.
> I later found out the requester's system was Vista 64 -
> which I'm told can't run any 16-bit dos or dpmi.
Blame AMD. Actually, I don't know why they chose to do that, nor why
Intel followed. Maybe they (like Intel with the original Itanium) knew
that compatibility would be slow anyways. Who knows.
Anyways, 64-bit is not required for normal use. I even question
whether it's required at all. Why do people keep switching to it then?
Fun??
http://www.geoffchappell.com/viewer.htm?doc=notes/windows/license/memory.htm
This guy apparently shows that all modern Windows support (and use)
PAE by default (due to NX) yet restrict you to only accessing less
than 4 GB due to "potential driver bugs". Eh?
Ed
> > I later found out the requester's system was Vista 64 -
> > which I'm told can't run any 16-bit dos or dpmi.
>
> Blame AMD. Actually, I don't know why they chose to do that, nor why
> Intel followed. Maybe they (like Intel with the original Itanium) knew
> that compatibility would be slow anyways. Who knows.
>
> Anyways, 64-bit is not required for normal use. I even question
> whether it's required at all. Why do people keep switching to it then?
> Fun??
Perhaps because they see it as the least obsolescent and the
direction in which Windows technology is going.
ken...@cix.compulink.co.uk
<d72b4cfb-ac15-4071...@o23g2000vbi.googlegroups.com>,
rug...@gmail.com (Rugxulo) wrote:
> Anyways, 64-bit is not required for normal use. I even question
> whether it's required at all. Why do people keep switching to it then?
> Fun??
32 bit Windows systems can only use 4GB of memory. Not all of that is
actually usable as memory mapped devices like graphics are included in
the total. Usable memory is around 3.4-3.5GB. I know that sounds like a
lot but Vista needs about 2GB to run properly. If you are ding something
that requires images for instance to be edited of CAD it is very easy to
run out of real memory. Off course people using those sorts of programs
are unlikely to need to run 16 bit programs.
Ken Young