Hello,
some years passed and now I would be interested to try Forth again.
First question: Which Forth is used nowadays for PCs under Windows11? I tried Win32Forth, ciForth and the old volksForth in an Oracle
VirtualBox. (gForth, bigForth, VFX, Swiftforth are too big for me for
the moment). What would you recommend?
The second question: All Forth systems I tried showed critical virus warnings from Google Chrome or Microsoft defender. Even an old
volksForth vf38141.arc - no modern archive utiliy could read this format
- was captured by Chrome. Win32Forth seems to be kidnapped on about each start by the Defender. I'm not very amused to turn all IT security off
to use Forth. Is there a chance to solve this issue?
some years passed and now I would be interested to try Forth again.
First question: Which Forth is used nowadays for PCs under Windows11? I tried Win32Forth, ciForth and the old volksForth in an Oracle
VirtualBox. (gForth, bigForth, VFX, Swiftforth are too big for me for
the moment). What would you recommend?
The second question: All Forth systems I tried showed critical virus warnings from Google Chrome or Microsoft defender. Even an old
volksForth vf38141.arc - no modern archive utiliy could read this format
- was captured by Chrome. Win32Forth seems to be kidnapped on about each start by the Defender. I'm not very amused to turn all IT security off
to use Forth. Is there a chance to solve this issue?
On 2026-06-08 11:40, clv2020 wrote:
some years passed and now I would be interested to try Forth again.
First question: Which Forth is used nowadays for PCs under
Windows11? I tried Win32Forth, ciForth and the old volksForth in an
Oracle VirtualBox. (gForth, bigForth, VFX, Swiftforth are too big
for me for the moment). What would you recommend?
A reliable way is to build the executable file by yourself.
Gforth can be build and used under WSL on Windows from a tarball; see
the instruction at:
<https://gforth.org/#:~:text=3DBuild%20from%20Tarball>
Aside from a number of dependencies and the lengthy build process,
Gforth is quite user-friendly.
Just to inform, that I was unsuccessful with building GForth on a GNU >operating system. Besides the build error,
the public PGP key they used
to sign the tarball is nowhere to be found. So I had to blind-trust,
Daniel Cerqueira <[email protected]> writes:
Just to inform, that I was unsuccessful with building GForth on a GNU >>operating system. Besides the build error,
Please provide details, possibly by email (less work for me to forward
it to Bernd).
ner.the public PGP key they used
to sign the tarball is nowhere to be found. So I had to blind-trust,
Try <https://savannah.gnu.org/people/viewgpg.php?user_id=3D9629>. With
that I get
[a4:/tmp:110662] gpg --verify gforth.tar.xz.sig
gpg: assuming signed data in 'gforth.tar.xz'
gpg: Signature made Wed 13 May 2026 04:48:59 PM CEST
gpg: using RSA key 449D4D0EA3D0470627C018EBF72D9493932DA067 gpg: Good signature from "Bernd Paysan <[email protected]>" [unknown]
[...]
gpg: Signature notation: manu=3D2,2.5+1.12,2,2
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the ow=
What should I do when I want to find out people's keys on Savannah ?
Hello,
some years passed and now I would be interested to try Forth again.
First question: Which Forth is used nowadays for PCs under Windows11? I tried Win32Forth, ciForth and the old volksForth in an Oracle
VirtualBox. (gForth, bigForth, VFX, Swiftforth are too big for me for
the moment). What would you recommend?
The second question: All Forth systems I tried showed critical virus warnings from Google Chrome or Microsoft defender. Even an old
volksForth vf38141.arc - no modern archive utiliy could read this format
- was captured by Chrome. Win32Forth seems to be kidnapped on about each start by the Defender. I'm not very amused to turn all IT security off
to use Forth. Is there a chance to solve this issue?
Hello,
some years passed and now I would be interested to try Forth again.
First question: Which Forth is used nowadays for PCs under Windows11? I tried Win32Forth, ciForth and the old volksForth in an Oracle VirtualBox. (gForth, bigForth, VFX, Swiftforth are too big for me for the moment). What would you recommend?
The second question: All Forth systems I tried showed critical virus warnings from Google Chrome or Microsoft defender. Even an old volksForth vf38141.arc - no modern archive utiliy could read this format - was captured by Chrome. Win32Forth seems to be kidnapped on about each start by the Defender. I'm not very amused to turn all IT security off to use Forth. Is there a chance to solve this issue?
Hello,
some years passed and now I would be interested to try Forth again.
First question: Which Forth is used nowadays for PCs under Windows11? I
tried Win32Forth, ciForth and the old volksForth in an Oracle
VirtualBox. (gForth, bigForth, VFX, Swiftforth are too big for me for
the moment). What would you recommend?
The second question: All Forth systems I tried showed critical virus
warnings from Google Chrome or Microsoft defender. Even an old
volksForth vf38141.arc - no modern archive utiliy could read this format
- was captured by Chrome. Win32Forth seems to be kidnapped on about each start by the Defender. I'm not very amused to turn all IT security off
to use Forth. Is there a chance to solve this issue?
For experimentation in a Win11 text console you might find MinForth interesting:
https://sourceforge.net/projects/minforth/files/
... (gForth, bigForth, VFX, Swiftforth are too big for me for
the moment). ...
What do you mean by "too big"
The second question: All Forth systems I tried showed critical virus
warnings from Google Chrome or Microsoft defender. Even an old
volksForth vf38141.arc - no modern archive utiliy could read this format
- was captured by Chrome. Win32Forth seems to be kidnapped on about each
start by the Defender. I'm not very amused to turn all IT security off
to use Forth. Is there a chance to solve this issue?
Without code signing, nearly all Windows Forths will be caught by Defender at some stage. However, adding relevant sections to the executable with something
like ResHacker reduces the issues greatly. The reason for all this is that Forth
usually requires a main section to have read, write and execute permissions. Such a section is often treated as a virus.
Stephen
16-bit DOS forth still interests, there is DX-Forth which tries to be modern and
is still maintained. It's also 'small' producing turnkeys as small as 6 KB :)
On Tue, 9 Jun 2026 12:14:07 +1000
dxf <[email protected]> wrote:
[]
16-bit DOS forth still interests, there is DX-Forth which tries to be modern andFeh; a 2k forth should be easy - it's 1k I'm trying for. (the trick is to
is still maintained. It's also 'small' producing turnkeys as small as 6 KB :)
use hash values for keywords).
Am 09.06.2026 um 01:01 schrieb minforth:
For experimentation in a Win11 text console you might find MinForth
interesting:
https://sourceforge.net/projects/minforth/files/
I just tried minforth. An interesting method to reduce the forth system
to small application. The transpiler of course does not know about words with Create does> I wrote by myself. Are there more drawbacks?
On 11/06/2026 3:54 am, Kerr-Mudd, John wrote:
On Tue, 9 Jun 2026 12:14:07 +1000
dxf <[email protected]> wrote:
[]
16-bit DOS forth still interests, there is DX-Forth which tries to be modern andFeh; a 2k forth should be easy - it's 1k I'm trying for. (the trick is to use hash values for keywords).
is still maintained. It's also 'small' producing turnkeys as small as 6 KB :)
SwiftX uses a recursive procedure to strip unused definitions from an initial compile. Such things were beyond by goal/ability which was to replicate something akin to Turbo-Pascal - a runtime kernel and a compiler that can be jettisoned.
So what's in your 2K (or 1K) forth and the goal in general?
: FCONSTANT \ ( f 'name' -- |r -- f) 12.6.1.1492 fp-number constant
create f, ['] f@ _<does ;
minforth <[email protected]> writes:
: FCONSTANT \ ( f 'name' -- |r -- f) 12.6.1.1492 fp-number constant
create f, ['] f@ _<does ;
The word that you call _<does is called SET-DOES> in Gforth
On 2026-06-11 17:28, Anton Ertl wrote:
minforth <[email protected]> writes:
: FCONSTANT \ ( f 'name' -- |r -- f) 12.6.1.1492 fp-number constant
create f, ['] f@ _<does ;
The word that you call _<does is called SET-DOES> in Gforth
In the name `does>`, the symbol `>` means that the following code up to
';' is a part of the semantics of the recent child of `create` (not the >containing definition).
In the name "set-does>" the symbol ">" is misleading.
The name '_<does' is also strange.
Why not simply choose the name `set-does`?
Or, even better, `set-latest-doer` ?
Overall, SET-DOES> is unambiguous and good enough.
Ruvim <[email protected]> writes:
On 2026-06-11 17:28, Anton Ertl wrote:
minforth <[email protected]> writes:
: FCONSTANT \ ( f 'name' -- |r -- f) 12.6.1.1492 fp-number constant
create f, ['] f@ _<does ;
The word that you call _<does is called SET-DOES> in Gforth
In the name `does>`, the symbol `>` means that the following code up to
';' is a part of the semantics of the recent child of `create` (not the
containing definition).
In the name "set-does>" the symbol ">" is misleading.
Yes. But given that Forth and Gforth continues to have DOES>,
SET-DOES> makes it clear to which word it is related. And I also find
it easier to remember that the spelling of DOES> does not differ
between DOES> and SET-DOES>.
The name '_<does' is also strange.
Given the explanation for the ">" in DOES>, <DOES points in the
direction where the xt should be pushed on the stack.
It's not clear to me why minforth prepended a "_".
Why not simply choose the name `set-does`?
Different spelling of the "DOES>" part.
Or, even better, `set-latest-doer` ?
Even more different. Gforth contains a number of words that change
the latest word, and they all start with SET-, not with SET-LATEST-
(one might see it as a problem that there are words that do not change
the latest word and that have also names starting with SET-).
And the
spelling of DOES> is even more different. Plus, we (at least in
Gforth source code, maybe also elsewhere) call run-time routines like
DOCOL DOCON DOVAR and DODOES doers, so I would expect that
SET-LATEST-DOER does what SET-EXECUTE does, not what SET-DOES> does.
Overall, SET-DOES> is unambiguous and good enough.
- anton
[email protected] (Anton Ertl) writes:
Overall, SET-DOES> is unambiguous and good enough.
But while we are at it, according to Andrew Haley early Forth had USE
with the same functionality as SET-DOES>.
Unfortunatley, Gforth contains a word USE with a different meaning:
'use' ( "file" - ) gforth-0.2
Open file as the current blocks file.
- anton
On 13/06/2026 4:22 am, Anton Ertl wrote:
[email protected] (Anton Ertl) writes:
Overall, SET-DOES> is unambiguous and good enough.
But while we are at it, according to Andrew Haley early Forth had USE
with the same functionality as SET-DOES>.
I don't recall that one. AFAIK the original definer was in the form:
: ... CONSTANT ;: ... ;
Presumably 2CONSTANT VARIABLE etc could also be used. Hard to find actual examples as vintage code is scarce.
In addition to CREATE DOES> F83 had:
: CONSTANT (S n -- )
CREATE , ;USES DOCONSTANT ,
a move closer to the xt variants.
DX-Forth implemented BUILD to support its compilation model. I saw no
reason to persist with the 'CREATE then patch' concept.
: CONSTANT ['] @ BUILD , ;
On 13/06/2026 4:22 am, Anton Ertl wrote:
[email protected] (Anton Ertl) writes:
But while we are at it, according to Andrew Haley early Forth had USE
with the same functionality as SET-DOES>.
I don't recall that one. AFAIK the original definer was in the form:
: ... CONSTANT ;: ... ;
Elizabeth D. Rather wrote:|..
Historical note: ;: was Chuck's original name for the structure which
for many years now has been CREATE DOES> (by separating the creation
from the instance behaviors you get more flexibility).
DX-Forth implemented BUILD to support its compilation model. I saw no
reason to persist with the 'CREATE then patch' concept.
: CONSTANT ['] @ BUILD , ;
You could do|
: foo ['] xt2 <does-create code1 ;
For basic systems xt2 is what you expect but for systems requiring
multiple xt's and/or other info, xt2 can be a system-specific struct |>containing all the information foo needs to create child words.
On 2026-06-12 17:52, Anton Ertl wrote:
And the
spelling of DOES> is even more different. Plus, we (at least in
Gforth source code, maybe also elsewhere) call run-time routines like
DOCOL DOCON DOVAR and DODOES doers, so I would expect that
SET-LATEST-DOER does what SET-EXECUTE does, not what SET-DOES> does.
I see. In that case, since Gforth already has `DODOES` (rather than >`DODOES>`), the name `SET-DOES` seems more appropriate.
does-code' ( xt1 - xt2 ) gforth-0.2 "to-does-code"If xt1 is the execution token of a child of a 'set-does>'-defined
DOES>-CODE and DOES>-CODE! and declare the other words obsolete.Maybe we will, but for now there is no desire to go there.
On 2026-06-13 03:14, dxf wrote:
On 13/06/2026 4:22 am, Anton Ertl wrote:
[email protected] (Anton Ertl) writes:
Overall, SET-DOES> is unambiguous and good enough.
But while we are at it, according to Andrew Haley early Forth had USE
with the same functionality as SET-DOES>.
I don't recall that one. AFAIK the original definer was in the form:
: ... CONSTANT ;: ... ;
Presumably 2CONSTANT VARIABLE etc could also be used. Hard to find actual >> examples as vintage code is scarce.
In addition to CREATE DOES> F83 had:
: CONSTANT (S n -- )
CREATE , ;USES DOCONSTANT ,
a move closer to the xt variants.
DX-Forth implemented BUILD to support its compilation model. I saw no
reason to persist with the 'CREATE then patch' concept.
: CONSTANT ['] @ BUILD , ;
BTW, do you consider `immediate` to be a from of patching as well?
As for `does>`, I also prefer to pass an xt and avoid patching. However, for the sake of backward compatibility and support for legacy programs, we have to retain `does>` as well.
I would like to introduce a basic factor of your `BUILD` that accept an xt and return other xt.
How to call such a word?
XXX ( xt1 -- xt2 )
Create a nameless definition with the execution token xt2.
If the data-space pointer is not aligned, reserve enough data space to align it. The new data-space pointer defines the data field associated with xt2. No data space is allocated in the data field. The execution semantics identified by xt2 are as follows: Place the data filed address associated with xt2 on the stack and execute xt1.
Ruvim <[email protected]> writes:
On 2026-06-12 17:52, Anton Ertl wrote:
And the
spelling of DOES> is even more different. Plus, we (at least in
Gforth source code, maybe also elsewhere) call run-time routines like
DOCOL DOCON DOVAR and DODOES doers, so I would expect that
SET-LATEST-DOER does what SET-EXECUTE does, not what SET-DOES> does.
I see. In that case, since Gforth already has `DODOES` (rather than
`DODOES>`), the name `SET-DOES` seems more appropriate.
There is no Forth word DODOES in Gforth. Howerver, there are the
following documented (i.e., supported) words that contain "DOES", with
the line numbers where they occur in the source code of the manual.
9061: does>
9103: set-does>
9620: const-does>
18986: dodoes:
18998: >does-code
19003: does-code!
An early occurence indicates that the word is more foundational and
more generally useful, while a late occurence indicates a word that
may be useful in specific places.
The documentation for the latter three words is:
'dodoes:' ( - addr ) gforth-0.6 "dodoes-colon"
The code address of a 'DOES>'-defined word.
does-code' ( xt1 - xt2 ) gforth-0.2 "to-does-code"If xt1 is the execution token of a child of a 'set-does>'-defined
word, xt2 is the xt passed to 'set-does>', i.e, the xt of the word that
is executed when executing xt1 (but first the body address of xt1 is
pushed). If xt1 does not belong to a 'set-does>'-defined word, xt2 is
0.
'does-code!' ( xt2 xt1 - ) gforth-0.2 "does-code-store"
Change xt1 to be a 'xt2 set-does>'-defined word.
So if we would rename, then we would probably introduce DODOES>:,
DOES>-CODE and DOES>-CODE! and declare the other words obsolete.Maybe we will, but for now there is no desire to go there.
On 13/06/2026 4:33 pm, Ruvim wrote:
On 2026-06-13 03:14, dxf wrote:
On 13/06/2026 4:22 am, Anton Ertl wrote:
[email protected] (Anton Ertl) writes:
Overall, SET-DOES> is unambiguous and good enough.
But while we are at it, according to Andrew Haley early Forth had USE
with the same functionality as SET-DOES>.
I don't recall that one. AFAIK the original definer was in the form:
: ... CONSTANT ;: ... ;
Presumably 2CONSTANT VARIABLE etc could also be used. Hard to find actual >>> examples as vintage code is scarce.
In addition to CREATE DOES> F83 had:
: CONSTANT (S n -- )
CREATE , ;USES DOCONSTANT ,
a move closer to the xt variants.
DX-Forth implemented BUILD to support its compilation model. I saw no
reason to persist with the 'CREATE then patch' concept.
: CONSTANT ['] @ BUILD , ;
BTW, do you consider `immediate` to be a from of patching as well?
IMMEDIATE alters a flag in the word's header that informs the compiler
how the word should be treated. Nothing is actually replaced.
As for `does>`, I also prefer to pass an xt and avoid patching.
However, for the sake of backward compatibility and support for legacy
programs, we have to retain `does>` as well.
That was my conclusion too. That said, there's little reason for me to actually use DOES> .
When you say it's a factor, do you mean xt1 is passed to BUILD in which case XXX is transparent?
I would like to introduce a basic factor of your `BUILD` that accept an xt and return other xt.
How to call such a word?
XXX ( xt1 -- xt2 )
Create a nameless definition with the execution token xt2.
If the data-space pointer is not aligned, reserve enough data space to
align it. The new data-space pointer defines the data field associated
with xt2. No data space is allocated in the data field. The execution
semantics identified by xt2 are as follows: Place the data filed address
associated with xt2 on the stack and execute xt1.>
On 2026-06-13 10:25, Anton Ertl wrote:
The documentation for the latter three words is:
'dodoes:' ( - addr ) gforth-0.6 "dodoes-colon"
The code address of a 'DOES>'-defined word.
What does the colon at the end mean?
I would hide that word in the attic and not show it to anyone ;-)
Ruvim <[email protected]> writes:
On 2026-06-11 17:28, Anton Ertl wrote:
minforth <[email protected]> writes:
: FCONSTANT \ ( f 'name' -- |r -- f) 12.6.1.1492 fp-number constant
create f, ['] f@ _<does ;
The word that you call _<does is called SET-DOES> in Gforth
In the name `does>`, the symbol `>` means that the following code up to >';' is a part of the semantics of the recent child of `create` (not the >containing definition).
In the name "set-does>" the symbol ">" is misleading.
Yes. But given that Forth and Gforth continues to have DOES>,
SET-DOES> makes it clear to which word it is related. And I also find
it easier to remember that the spelling of DOES> does not differ
between DOES> and SET-DOES>.
The name '_<does' is also strange.
Given the explanation for the ">" in DOES>, <DOES points in the
direction where the xt should be pushed on the stack. It's not clear
to me why minforth prepended a "_".
Why not simply choose the name `set-does`?
Different spelling of the "DOES>" part.
Or, even better, `set-latest-doer` ?
Even more different. Gforth contains a number of words that change
the latest word, and they all start with SET-, not with SET-LATEST-
(one might see it as a problem that there are words that do not change
the latest word and that have also names starting with SET-). And the spelling of DOES> is even more different. Plus, we (at least in
Gforth source code, maybe also elsewhere) call run-time routines like
DOCOL DOCON DOVAR and DODOES doers, so I would expect that
SET-LATEST-DOER does what SET-EXECUTE does, not what SET-DOES> does.
Overall, SET-DOES> is unambiguous and good enough.
- anton
dxf <[email protected]> writes:
On 13/06/2026 4:22 am, Anton Ertl wrote:
[email protected] (Anton Ertl) writes:
But while we are at it, according to Andrew Haley early Forth had USE
with the same functionality as SET-DOES>.
Actually, he wrote in <[email protected]>:
| That's not wildly different from polyFORTH II, which had USE:
|
| CREATE FOO ... blah ... <address> USE
|
| USE takes the address of some runtime code and patches it into the
| code field of the most recent definition. I think that syntax is a
| little more pleasant than your above.
So it's probably like Gforth's SET-EXECUTE (which takes a machine-code address), not like Gforth's SET-DOES> (which takes an xt). And
polyForthII is not that early.
On 2026-06-13 12:20, dxf wrote:[...]
On 13/06/2026 4:33 pm, Ruvim wrote:
On 2026-06-13 03:14, dxf wrote:
[...]DX-Forth implemented BUILD to support its compilation model. I saw no >>>> reason to persist with the 'CREATE then patch' concept.
: CONSTANT ['] @ BUILD , ;
I would like to introduce a basic factor of your `BUILD` that accept
an xt and return other xt.
How to call such a word?
XXX ( xt1 -- xt2 )
Create a nameless definition with the execution token xt2.
If the data-space pointer is not aligned, reserve enough data space
to align it. The new data-space pointer defines the data field
associated with xt2. No data space is allocated in the data field.
The execution semantics identified by xt2 are as follows: Place the
data filed address associated with xt2 on the stack and execute xt1.
body` to obtain the data field address from the xt2. That is why thepart "datafield" is present in the name.
When you say it's a factor, do you mean xt1 is passed to BUILD in
which case XXX is transparent?
I mean that BUILD can be defined using XXX as follows:
: BUILD ( xt1 "<spaces>name" -- )
XXX ( xt2 ) PARSE-NAME ENLIST
;
Where the word ENLIST places a new word to the compilation word list.
ENLIST ( xt1 sd.name -- )
Place a named definition into the compilation word list; the
definition's name matches the character string sd.name, and the
definition's execution semantics are equivalent to the execution
semantics identified by xt1.
One of the issues I currently see is that, for `>body` to work
correctly, `enlist` must guarantee either the identity of the execution token:
t{ :noname ; dup s" foo" enlist -> ' foo }t
or, at least, the identity of the data field (and other associated properties):
t{ create bar ' bar >body ' bar s" foo" enlist -> ' foo >body }t
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,123 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 39:14:30 |
| Calls: | 14,372 |
| Calls today: | 1 |
| Files: | 186,380 |
| D/L today: |
7,905 files (2,328M bytes) |
| Messages: | 2,540,712 |