Last beta release of ciforth
Albert van der Horst
that I expect to change. This is version 3.275
Compared to the latest version 3.224 I have added a dpmi ("windows")
version, options and a uniform compilation to stand alone system. That
is uniform across Linux, Windows and MSDOS.
I like it.
hello.frt contains
"
: hello "hello worlds!" TYPE CR ;
"
Then an executable is generated by
"
lina -c hello.frt
"
This compilation, scripting and other options are *not*
in the kernel, but are load-on-demand from a single library file.
You can download from my site below :
- the generic system (to generate these forths and a lot of others)
- lina the linux i386 binary distribution (64 Mbyte 32 bits.)
- wina the DPMI binary distribution (4 Mbyte 32 bits)
- mina the msdos binary distribution (64 kbyte 16 bits)
The balance between executable and documentation is about right:
binary 22 Kbyte, documentation 600 kByte.
After improving the appearance of the documentation this will
become version 4.0 , and I will undertake to maintain the above
3 versions.(Accepting defect ("bug") reports and the like.)
(Why 4.0? Because this is in fact figForth 4.0)
A binary version that boots from floppy or hard disk directly into
Forth is also downloadable, but defect reports will not be tracked or
stored in the defects database.
ciforth ("close to iso") forth is as close to ISO as is practical
for minimal system.
ciforth ("computer intelligence forth") is a spin off from my
sabbatical where I tried to do some groundwork for my ai aspirations.
ciforth is a classic indirect threaded forth implementation
assembled from a single source file. All ciforth's assembler
sources are generated, together with glossary documentation, from
a single master source by the generic system.
All of the above including the source and tools of the generic
system is available under the GPL license.
http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Gary Chanson
"Bill McCarthy" <WJ...@pobox.com> wrote in message
news:vlVS7.114$u4....@news-reader.ntrnet.net...
> On Fri, 14 Dec 2001 20:30:26 GMT, Albert van der Horst wrote:
> >
> >You can download from my site below :
> >- the generic system (to generate these forths and a lot of others)
> >- lina the linux i386 binary distribution (64 Mbyte 32 bits.)
> >- wina the DPMI binary distribution (4 Mbyte 32 bits)
> >- mina the msdos binary distribution (64 kbyte 16 bits)
>
> DOS thing? The executable is a COM file. Are you considering having a
> native version for Win NT/2K/XP?
Yes, DPMI is "DOS Protected Mode Interface" and it's what's called a
"DOS extender". A DPMI based program does not have any access to Windows
APIs even if it's running under Windows.
--
-GJC
-gcha...@shore.net
-War is the last resort of the incompetent.
Albert van der Horst
Gary Chanson <gcha...@no.spam.shore.net> wrote:
>
>"Bill McCarthy" <WJ...@pobox.com> wrote in message
>news:vlVS7.114$u4....@news-reader.ntrnet.net...
>> On Fri, 14 Dec 2001 20:30:26 GMT, Albert van der Horst wrote:
>> >
>> >You can download from my site below :
>> >- the generic system (to generate these forths and a lot of others)
>> >- lina the linux i386 binary distribution (64 Mbyte 32 bits.)
>> >- wina the DPMI binary distribution (4 Mbyte 32 bits)
>> >- mina the msdos binary distribution (64 kbyte 16 bits)
>>
>> I took a look at the wina version. What's with the DPMI. Isn't that a
>> DOS thing? The executable is a COM file. Are you considering having a
>> native version for Win NT/2K/XP?
>
> Yes, DPMI is "DOS Protected Mode Interface" and it's what's called a
>"DOS extender".
Since when is it illuminating to call Windows a "DOS-extender"?
DPMI is the part of the Windows operating system facilities
that is portable across the most versions of Windows.
To be honest, it might be abandoned in newer versions,
and it is not supported by wine inasfar I understand.
It has its advantages:
It is not subject to DLL hell, registry etc.
Being a .COM or old fashioned .EXE file has the advantage that
the program is started in its own "dos" window. That keeps
things simple, I like that.
Furthermore you don't get the stupid message
" This program must be run under Microsoft Windows"
if you start the program from COMMAND.COM under Windows.
A disadvantage is that a saved program image cannot be
larger that 64K (.COM) or 1M (.EXE).
I will add an extension to save in the Windows native .EXE
format after the first complaint of an actual user about
the 1M limit for turnkey programs.
> A DPMI based program does not have any access to Windows
>APIs even if it's running under Windows.
What makes you think that wina.com has any less access as any protected
mode program running at protection level 3? What matters are call gates,
segments and privilege levels. And knowing the addresses of the
subroutines to call, of course.
The correct proposition is :
"wina.com comes without any facilities to use Windows API's"
This is correct. Much as I like to have those facilities,
I consider them loadable extensions. I wouldn't want to have
them in the kernel anyway.
wina.com is just a "close to ISO" Forth that requires "some sort of
Windows" to run. It has a comfortable 32 Mbyte (or whatever you configure)
of dictionary space, the core wordset,the exception wordset (with the
restriction that the throw codes not comply to the standard) and
practically the whole file wordset available. That amounts to be able to
run a substantial part of portable programs.
Use it if that suits you.
De groeten
Albert
--
Gary Chanson
"Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in message
news:GoG969.C76...@spenarnc.xs4all.nl...
>
> Since when is it illuminating to call Windows a "DOS-extender"?
> DPMI is the part of the Windows operating system facilities
> that is portable across the most versions of Windows.
> To be honest, it might be abandoned in newer versions,
> and it is not supported by wine inasfar I understand.
DPMI is a DOS extender. It happens that it was created by Microsoft and
implemented by them as part of Windows, but it's still not "Windows". DPMI
is also implemented by every DOS memory manager. The best DPMI
implementation I've tested is QEMM by Quaterdeck and has absolutely nothing
to do with Windows.
DPMI does not give you any access to Windows APIs.
> It has its advantages:
> It is not subject to DLL hell, registry etc.
> Being a .COM or old fashioned .EXE file has the advantage that
> the program is started in its own "dos" window. That keeps
> things simple, I like that.
> Furthermore you don't get the stupid message
> " This program must be run under Microsoft Windows"
> if you start the program from COMMAND.COM under Windows.
Are you STILL running Win3.0? Anything newer does not behave this way.
> The correct proposition is :
> "wina.com comes without any facilities to use Windows API's"
> This is correct. Much as I like to have those facilities,
> I consider them loadable extensions. I wouldn't want to have
> them in the kernel anyway.
You can't.
Bill McCarthy
>Since when is it illuminating to call Windows a "DOS-extender"?
>DPMI is the part of the Windows operating system facilities
>that is portable across the most versions of Windows.
>To be honest, it might be abandoned in newer versions,
>and it is not supported by wine inasfar I understand.
>
>It has its advantages:
>It is not subject to DLL hell, registry etc.
>Being a .COM or old fashioned .EXE file has the advantage that
>the program is started in its own "dos" window. That keeps
>things simple, I like that.
>Furthermore you don't get the stupid message
>" This program must be run under Microsoft Windows"
>if you start the program from COMMAND.COM under Windows.
DPMI and COMMAND.COM is stuff out of the 80's. I just checked my hard
drive and found nothing called COMMAND.COM (Windows 2000).
Why bother wasting your time developing for DOS machines?
Bill
Albert van der Horst
> Are you STILL running Win3.0? Anything newer does not behave this way.
I am running Windows 3.11 . It is newer than Windows 3.0 ,
and yes it behaves this way.
I bought an early version of Windows '95, the one that was not
really 32 bits and required a pre-installed Windows 3.x.
That was the last time I bought a Microsoft product.
Unless I am testing software as a service for you guys out there,
I run windows for 20 minutes a month to do my electronic banking.
(So there is no reason to pity me.)
>> I consider them loadable extensions. I wouldn't want to have
>> them in the kernel anyway.
>
> You can't.
If you can explain the technical reason, I am very interested.
Saves me the time of trying. Note that the design of wina.com
is such that *if* you can load it, you can have it in your kernel
with a sequence like
"
WINA/A
"FILEAPI.FRT" INCLUDED
REQUIRE SAVE-SYSTEM
"WINAPLUS.EXE" SAVE-SYSTEM
BYE
"
If this adds 10 Kbyte I would still consider it a kernel.
Note that I do not base my Forth on c, and hence are not
restricted by whatever is provided by some c-compiler.
The library provides an assembler, that can be used in
"FILEAPI.FRT" . There is a facility to load the
assembler high, such that it doesn't end up in the
saved kernel.
--
Met vriendelijke groeten
Albert
Albert van der Horst
Sorry to hear that you must make do without a shell.
So you are running Windows 2000.
Would you do me a favour? Try out wina and see if it runs as an ISO
("ANSI") system under Windows 2000. (It works under Windows NT, and
2000 is supposedly its successor.) I am very interested.
But indeed the SYSTEM command could not possibly work
without a shell. SYSTEM is not required for compliance to the
standard though.
>Why bother wasting your time developing for DOS machines?
Because 90%+ of the world is running DOS machines. What kind of
question is that?
>
>Bill
--
Albert
Gary Chanson
>
> >Why bother wasting your time developing for DOS machines?
>
> Because 90%+ of the world is running DOS machines. What kind of
> question is that?
90%+ of the world is running Windows, not DOS. You're living in the
wrong decade!
Gary Chanson
> In article <XggT7.1473$df.1...@news.shore.net>,
> Gary Chanson <gcha...@no.spam.shore.net> wrote:
> >
> > DPMI is a DOS extender.
> Technically you are wrong. DPMI is an interface standard.
It is an interface standard which specifies a DOS extender (which, by
the way NEVER mentions Windows in any way). If you don't have a copy of the
standard, I can send it to you.
> I am running Windows 3.11 . It is newer than Windows 3.0 ,
> and yes it behaves this way.
> I bought an early version of Windows '95, the one that was not
> really 32 bits and required a pre-installed Windows 3.x.
> That was the last time I bought a Microsoft product.
> Unless I am testing software as a service for you guys out there,
> I run windows for 20 minutes a month to do my electronic banking.
> (So there is no reason to pity me.)
I won't pity you, but Win3 is of no interest.
> If you can explain the technical reason, I am very interested.
> Saves me the time of trying.
All Windows API functions are in DLLs and the only way to access them is
by using the Windows DLL interface. If you can't execute LoadLibrary() and
GetProcAddress(), you can't execute Windows API functions. DPMI does not
support theses functions.
Marc A. Pelletier
Gary Chanson wrote:
> "Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in message
> news:GoIqxE.JCE...@spenarnc.xs4all.nl...
>
>>>Why bother wasting your time developing for DOS machines?
>>>
>>Because 90%+ of the world is running DOS machines. What kind of
>>question is that?
>>
>
> 90%+ of the world is running Windows, not DOS. You're living in the
> wrong decade!
Bzzzt! Better luck next time. Unless you are talking about NT and its
spawn (2000 included), "Windows" is not an OS. It is an environment
running over DOS. Most of the world is running 95/98. Ergo, most of
the world is running DOS.
It's horrible, isn't it?
-- Marc A. Pelletier
Jeff Fox
> 90%+ of the world is running Windows, not DOS.
> You're living in the wrong decade!
98% of the computers on the planet that I am on
are embedded computers w/o Windows. Also on
the planet that I am on about 1% of the people
in the world are running Windows on a computer.
Gary Chanson
"Marc A. Pelletier" <ma...@mutatingmedia.com> wrote in message
news:3C200272...@mutatingmedia.com...
>
> Bzzzt! Better luck next time. Unless you are talking about NT and its
> spawn (2000 included), "Windows" is not an OS. It is an environment
> running over DOS. Most of the world is running 95/98. Ergo, most of
> the world is running DOS.
I'm including all flavors.
Win9x does not run "over DOS". Once it's running, it only uses 16 bit
DOS code when a program forces it to for backward compatibility.
> It's horrible, isn't it?
Not at all.
Gary Chanson
"Jeff Fox" <f...@UltraTechnology.com> wrote in message
news:3C200650...@UltraTechnology.com...
But, 90%+ of the people using personal computers are running Windows.
The comment was in reference to use of DOS.
Boy, you are good at being dis-ingenuous.
Jeff Fox
> But, 90%+ of the people using personal
> computers are running Windows.
I did know that you were talking about 90%
of the 1% when you said the world.
I did just bite my tongue on the "what kind
of comment was that?" question.
> Boy, you are good at being dis-ingenuous.
If it does not fit you must aquit! ;-)
Bill McCarthy
>In article <WFhT7.117$u4....@news-reader.ntrnet.net>,
>Bill McCarthy <WJ...@pobox.com> wrote:
>>On Sun, 16 Dec 2001 18:39:45 GMT, Albert van der Horst wrote:
>>
>>
>>DPMI and COMMAND.COM is stuff out of the 80's. I just checked my hard
>>drive and found nothing called COMMAND.COM (Windows 2000).
>
>Sorry to hear that you must make do without a shell.
>
>So you are running Windows 2000.
>Would you do me a favour? Try out wina and see if it runs as an ISO
>("ANSI") system under Windows 2000. (It works under Windows NT, and
>2000 is supposedly its successor.) I am very interested.
>
>But indeed the SYSTEM command could not possibly work
>without a shell. SYSTEM is not required for compliance to the
>standard though.
Win NT/2K/XP come with a shell called CMD.EXE - but many, if not most
people that program use 4NT.EXE.
WINA.COM does run, but takes a few seconds to come up. NTVDM.EXE gets
started (it not mentioned in the help system - therefore it's
undocumented). It persists, even after I leave WINA - until I shut down
CMD or 4NT.
>>Why bother wasting your time developing for DOS machines?
>
>Because 90%+ of the world is running DOS machines. What kind of
>question is that?
I surprised its that high, but now that nearly all Wintel machines are
being shipped with XP, that's going to change. But what's relevant is
the proportion of forth wintel users using DOS (including Win 95/98/ME).
Most know better (or are game players).
Bill
Albert van der Horst
I am very much aware of that. In a discussion with some one
your level I would never have phrased it like that.
But sometimes you have to adapt to the public.
Yes I am living in the wrong decade.
I am living in the next (X-Unix-Linux) decade.
Born way to early.