Re: The Ulimate Editor

Marcel Hendrix wrote: 
"Jenny Brien" <jennifer@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes Re: The Ulimate Editor
[..]

It's a pity all the major Windows Forths seem to interface in a different way. Perhaps it's time for a publication standard? 


[snipped]

I do NOT like to have Forth code like that shown for Win32Forth: it firmly locks down that Forth to Windows (and because the parameter
order is reversed from the OS spec., the code can never be reliably exchanged between Windows Forth systems ... ). 

I'm not quite with you on this one; if Windows declares a call like

FARPROC GetProcAddress(
  HMODULE hModule,
  LPCSTR lpProcName
);

then to invoke this;

 c" LoadLibrary" 0 call GetProcAddress

(strings in WIn32Forth are automatically null terminated). The order of the parameters is "stack natural"; there's no swapping of the parameters before the call.

In fact, the call statement is not required in the latest version; the word (apart from case sensitivity) is tickable etc, and looks just like an ordinary word.

 ' GetProcAddress value getproc
 c" LoadLibrary" 0 getproc


Before it's too late, interface layers to common functionality should
be specified (and agreed upon). It doesn't seem that hard to me, but
it never seems to takes off.


In Win32Forth, the words are currently

 WINLIBRARY name.dll

identifies the library.

 n PROC name

n is the number of parameters; it's only for documentation use. PROCs are not tied to libraries; every declared library is searched for the proc. This isn't 100% satisfactory if the same name is in more than 1 library. name is case preserved. (In fact, the PROC statement can be omitted much of the time; it's use has become largely ceremonial.)

 AS altname

allows an alternative name for the last declared PROC, where case is not preserved.

 CALL name  ( or altname)

CALL is optional.

 n CALLBACK: name ... ;

defines a callback with n parameters (again, stack natural). __CDECL can be as a modifier to support other than the normal __STDCALL convention.

That's as things stand currently; I'm working on an update to address some of the problems associated with external variables, PROCs with duplicate names etc, and to support exports.

Basically, I'll agree to anything that allows me to treat the name of a function as a normal Forth word, without too much declaration fluff; preferably just the name of the library it lives in, as I can do right now in Win32Forth. It's much more flexible currently than I think you give it credit for.

--
Regards
Alex McDonald
.

Relevant Pages

  • Re: procs and concatenations
    ... The following is the system supplied Cobol compile procedure, ... FJS.PDSE.COBOL contains my private source code. ... Obviously I could have APPL.PROD.COPYLIB in the proc and just have the ... calling JCL concatenate both libraries explicitly. ...
    (bit.listserv.ibm-main)
  • Tcl 8.4 can kill Windows XP
    ... days have a "reliable" windows XP ... The same Tcl code as been tested on RH Linux and runs error ... proc ifStop { ... set fmt %y%m%d-%T ...
    (comp.lang.tcl)
  • procs and concatenations
    ... to, if desired, add just their own private library statements in their JCL. ... Obviously I could have APPL.PROD.COPYLIB in the proc and just have the ... calling JCL concatenate both libraries explicitly. ...
    (bit.listserv.ibm-main)
  • newbie - proc help
    ... I'm trying to get a proc to work, ... gets stdin user ... puts "you entered no to Fred libraries"} ...
    (comp.lang.tcl)
  • Re: UK pound symbol and isql.exe
    ... isqlw and running and then creating the proc by piping in. ... > page installed with Windows XP appears correctly in a command prompt ...
    (microsoft.public.sqlserver.programming)
Loading