OpenEuphoria

Re: C_FUNC in DOS

• Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Jan 06, 1999
• 455 views

Robert Craig wrote:
>In WIN32, calling C routines is much easier.

Why not add support for using .OBJ files ?
As a counterpart to the Win32-call_func () one that works with .OBJ files
rather than .DLL files.

There are a number of advantages:
You could strip down lots of these 'machine_function's you have currently
built-in. This way we could choose which parts of code to be loaded at
run-time. Loading the object file, etc. is done by wrappers just like now.
Only they dont call the built-in routines machine_func () and machine_proc
(), now they either call a DLL (win32) or an .OBJ (dos32).

I mean, take the whole built-in graphics engine, my binded Botmatch contains
both the Neil engine, the Watcom graphics engine, etc.

Also, it might be better, if more of the includes are pure Euphoria. It
saves a lot of huge
watcom libraries that are currently loaded, and it is better maintainable.
For example things like dir (). There are already counterparts that also
read the LONG_NAME attribute of directories and files, in pure Euphoria. Why
not use such a routine rather than the built-in one ? (which does not give
the long-filename on DOS32)

Im personally also in favor of the naming convention to use EXD as
the extension of DOS32 *only* files. And why not try to keep things as
platform independent as they can be. For example, a real log window gets the
'puts (1, ... )' and an input (0) is done in the log window. (it only shows
up when we actually puts or input something). And where is the counterpart
of the graphics library with Win32 ? It is possible to have a 100%
compatible counterpart. Or take 'message_dialog', why not have a DOS32
counterpart ? Not much effort, but great for portability.

Maybe a special routine that works on both platforms and instead of action,
rather designed towards a certain goal, is better: maybe something called
'log_output' and
'log_input', together with 'gui_ask' and 'gui_tell' ?

And yes, we could write all this ourselves, but specific routines like sound

() and wildcard-matching are also available. And the for the above named
routines its much more logical to have those standard with the program, than
with specific ones like that.

Also I suggest a small 'compiler-switch'.
Just a:

with 1
-- This is read by the interpreter

wihout 1
-- This is not

with 0
-- This is not

without 0
-- This is read by the interpreter

'trace' etc. are just special cases, and the include file default.e is
*always* included. (it should contain things like: the platform () function,
and other maybe certain other small things)

This way, we could say:

with platform() = WIN32

with platform() = DOS32

Saves speed, and often we have total different routines, or want to
overwrite built-in routines just in ONE of the two currently supported
operating systems. (and yes, I know the trick around that)

Lastly, I hope that you can find a way to determine when 'inlining' will be
faster. Off course only local routines should be inlined. (you could just
move this part to the shrouder/binder to avoid name-conflicts with local
declared routines, it would solve lots of problems and increase speed)

Ralf N.
nieuwen at xs4all.nl
ralf_n at email.com