Re: Standardisation between Win libraries
Hello Derek, you wrote:
> ----- Original Message -----
> From: "Juergen Luethje"
>
>> Me wrote:
>>
>>> Hello Dave, you wrote:
<snip>
>>>> Is it possible for you all to talk together and decide on a standard set
>>>> of include files for the definitions of Windows constants ie. for
>>>> WM_PAINT, WM_MOUSEMOVE, VK_SPACE, VK_LEFT, etc? and/or other aspects.
>>>>
>>>> With one single set of includes it would make the use of Euphoria for
>>>> Windows soooo much easier.
>>>
>>> <snip>
>>>
>>> Yep! I also strongly vote for a modular approach.
>>> For all Windows programming, there is a "smallest common denominator":
>>> the wrapping of the Windows API! Whatever we do, we need constant and
>>> routine declarations. It would be really valuable, to have some
>>> _standard_ files, that wrap the Windows API. These files only should
>>> contain:
>>>
>>> - global constant ..
>>> - a = open_dll(..)
>>> - idFuncX = define_c_func(a, ..)
>>> - global function FuncX(..)
>>> ..
>>> return c_func(idFuncX, ..)
>>> end function
>>> - (same for procedures, of course)
>>>
>>> Maybe I forgot something, but I hope you see my point. These wrappers
>>> should not contain any "bells and whistles".
>>> The API programmers can use it, and the programmers of the advanced
>>> libraries (like Win32Lib) also need something like that anyway.
>
> This idea is fine so long as CONSTANT LITERALS and ROUTINE DECLARATIONS
> are contained in different include files.
Yes, I think this is a good idea anyway. In case someone wants it, it's
easy to combine different files (logically or physically). The other way
round, splitting one huge file into small pieces if needed, is not that
easy.
> This is because win32lib does not do a simple "define_c_func" as a
> constant. It uses variables because the initial declaration does not
> actually link to the DLL, that only gets done when and if the
> application uses the API routine.
Ah, I see. When I first read this, I was thinking of something along the
lines of the following sample code:
---------------------------[ File user32.ew ]---------------------------
include dll.e
atom user32
user32 = -1
procedure link_user32()
user32 = open_dll("user32.dll")
if user32 = 0 then
-- error
end if
end procedure
--====================================================================--
integer idLoadCursor idLoadCursor = 0
global function LoadCursor (atom hInstance, atom lpCursorName)
-- Initialisation
if user32 = -1 then link_user32() end if
if idLoadCursor = 0 then
idLoadCursor = define_c_func(user32, "LoadCursorA",
{C_INT, C_POINTER}, C_INT)
if idLoadIcon = -1 then
-- error
end if
end if
-- Actual function call
return c_func(idLoadCursor, {hInstance, lpCursorName})
end function
---------=---------=---------=---------=---------=---------=--------
integer idLoadIcon idLoadIcon = 0
global function LoadIcon (atom hInstance, atom lpIconName)
-- Initialisation
if user32 = -1 then link_user32() end if
if idLoadIcon = 0 then
idLoadIcon = define_c_func(user32, "LoadIconA",
{C_INT, C_POINTER}, C_INT)
if idLoadIcon = -1 then
-- error
end if
end if
-- Actual function call
return c_func(idLoadIcon, {hInstance, lpIconName})
end function
---------=---------=---------=---------=---------=---------=--------
But then I looked at Win32Lib and saw, that it handles the linking to
DLLs in a more complex way ...
>>> The problem is _not_ to write the code, there are already such API
>>> wrapper files. I for instance use a set of files, that Chris Bensler
>>> sent me privately. Thanks again, Chris. 
>>>
>>> But this isn't the solution. It would be really great to have _standard_
>>> wrappers for this purpose, and the programmers of the advanced libraries
>>> should use them, rather than their own wrappers.
>
> I agree for constant literals.
So we should a least try do define/create such a standard.
> However, for performance reasons, I do
> not link in the hundreds of API routines at program startup, they only
> get linked in as they are used.
>
>>> The problem is, that there currently is no agreement, which files
>>> actually should be "the standard".
>>
>> Sometimes I'm not very good in expressing myself, especially in a
>> foreign language.
>>
>> The main problem regarding this issue actually seems to be, that there
>> is no broad agreement on this list, that having a very basic Windows API
>> standard wrapper is a good idea at all ...
>
> I have no problem with this idea. But win32lib is not a low-level
> wrapper for Windows. It simply can't use a 'statically' linked DLL such
> as you propose.
>
> Also note that the thousands of constant literals would always all be
> assigned and placed in RAM by the interpreter. So if your code only
> need a few dozen of these constants, you will have lots of wasted RAM and
> progam startup time wasted.
I see. But anyway it would be a good idea IMHO, to have a huge
collection of constant literals. Then it's simply a mattor of search,
copy, and paste, do get them in our code.
(That's even more important for routine declarations. Before I had
Chris's API wrapper files, I always had to look in win32api files
provided by PowerBASIC for the routine declarations, and translate
them to Euphoria. That was a pain.)
Including only the constant literals and routine declarations in our
programs, that are actually needed, would be a good job for a
preprocessor, IMHO. Or for instance a "generic" IDE (as it is
apparently planned ATM could provide the possibility to insert
the needed declarations into the code by choosing them from a list.
Also, including many unneeded constant literals and routine declarations
does *not* slow down a bound or a shrouded program.
Therefore I would really like to have an additional option for shrouding,
say '-very clear' or '-preserve', that will do the same as '-clear',
but not remove comments and indenting white space. Preserving the
comments and the indentation will be useful anyway, when we want to ship
a single source file (unless the file is very big). Rob, what do you
think?
Well, I'm just trying to collect some ideas ...
Best regards,
Juergen
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
|
Not Categorized, Please Help
|
|
