1. DLL trouble (continued)
Thanks Bernie, Derek and CChris for your replies.
The function I'm using does actually take a struct argument, not just a pointer
to a struct.
(I tried it that way hoping the documentation was wrong, but it wasn't.) It's
true that this
isn't a very common occurance, but it does happen. Here's the function I'm
currently working
with:
"SetFilePOinterEx" in kernel32.dll (see
http://msdn2.microsoft.com/en-us/library/aa365542.aspx )
The LARGE_INTEGER is a 64-bit struct. I did manage to get the C_DOUBLE value to
work, e.g. }}}
<eucode>
include dll.e
global constant kernel32 = open_dll("kernel32.dll"),
cSetFilePointerEx = define_c_func(kernel32, "SetFilePointerEx",
{C_UINT, -- handle of open file
C_DOUBLE, -- bytes to move
C_POINTER, -- pointer to new file pointer
C_UINT}, -- dwMoveMethod (see article)
C_UINT) -- Boolean return value
</eucode>
{{{
as it's the same size (64-bit), but only with the value of zero, since zero is
encoded the same for an integer
and a floating-point number. But for all other numbers, Euphoria will be taking
the atom I use in the function
and convert it to its floating-point equivalent, which is far different from the
original bit-pattern.
I thought about the (complicated) possibility of writing a function to
anticipate this conversion and put in the
function an atom that would convert to what I really want, but this is
impossible because there's no perfect 1:1
conversion between 64-bit integers and floating-point integers, and a lot of the
bit encodings represent zero,
denormals, infinity, and NaNs (not-a-number).
-----
re:
> Does the define_c_var routine not work for you?
and
> Use define_c_var(entry_point,var_name). That will give you an address to
> peek/poke at.
Maybe I'm wrong, but I'm quite sure that these (and a boat-load of other
constants) are defined in kernel32.dll:
MAX_PATH
INVALID_HANDLE_VALUE
ERROR_FILE_NOT_FOUND (and other error codes)
FILE_ATTRIBUTE_COMPRESSED (and other attributes)
GENERIC_READ (and other Generic Access Rights)
MAXIMUM_ALLOWED
ACCESS_SYSTEM_SECURITY
READ_CONTROL (and other Standard Access Rights)
FILE_SHARE_READ (etc.)
CREATE_ALWAYS (and other creation dispositions)
FILE_FLAG_BACKUP_SEMANTICS (and other flags)
(etc....)
I've tried several of these with the define_c_var function, but with no success,
e.g. }}}
<eucode>
include dll.e
global constant kernel32 = open_dll("kernel32.dll"),
myMAX_PATH = define_c_var(kernel32, "MAX_PATH")
</eucode>
{{{
define_c_var always returns -1.
Maybe I'm just confused - are constants ever visible in a .dll, or only in the
source that created it?
Am I limited to real VARIABLES?
(The constants aren't such a big deal as the passing of struct-type varibles
above. I can always get the values of the
constants and define them myself, but just thought I'd mention it too in case
anyone had an idea.)
Looking forward to any help you can give. Thanks!
2. Re: DLL trouble (continued)
K. Einfeldt wrote:
> The function I'm using does actually take a struct argument, not just a
> pointer
> to a struct.
> (I tried it that way hoping the documentation was wrong, but it wasn't.) It's
> true that this
> isn't a very common occurance, but it does happen. Here's the function I'm
> currently working
> with:
> "SetFilePOinterEx" in kernel32.dll (see <a
> href="http://msdn2.microsoft.com/en-us/library/aa365542.aspx">http://msdn2.microsoft.com/en-us/library/aa365542.aspx</a>
> )
>
> <font color="#330033">The LARGE_INTEGER is a 64-bit struct. I did manage
> </font><font color="#0000FF">to </font><font color="#330033">get the C_DOUBLE
> value </font><font color="#0000FF">to
> work, e.g. }}}
<eucode>
>
> include dll.e
> global constant kernel32 = open_dll("kernel32.dll"),
> cSetFilePointerEx = define_c_func(kernel32, "SetFilePointerEx",
> {C_UINT, -- handle of open file
> C_DOUBLE, -- bytes to move
> C_POINTER, -- pointer to new file pointer
> C_UINT}, -- dwMoveMethod (see article)
> C_UINT) -- Boolean return value
> </eucode>
{{{
> as it's the same size (64-bit), but only with the value of zero, since zero
> is encoded the same for an integer
> and a floating-point number. But for all other numbers, Euphoria will be
> taking
> the atom I use in the function
> and convert it to its floating-point equivalent, which is far different from
> the original bit-pattern.
>
> I thought about the (complicated) possibility of writing a function to
> anticipate
> this conversion and put in the
> function an atom that would convert to what I really want, but this is
> impossible
> because there's no perfect 1:1
> conversion between 64-bit integers and floating-point integers, and a lot of
> the bit encodings represent zero,
> denormals, infinity, and NaNs (not-a-number).
>
> -----
>
> re:
> > Does the define_c_var routine not work for you?
> and
> > Use define_c_var(entry_point,var_name). That will give you an address to
> > peek/poke
> at.</font></i>
>
> Maybe I'm wrong, but I'm quite sure that these (and a boat-load of other
> constants)
> are defined in kernel32.dll:
> MAX_PATH
> INVALID_HANDLE_VALUE
> ERROR_FILE_NOT_FOUND (and other error codes)
> FILE_ATTRIBUTE_COMPRESSED (and other attributes)
> GENERIC_READ (and other Generic Access Rights)
> MAXIMUM_ALLOWED
> ACCESS_SYSTEM_SECURITY
> READ_CONTROL (and other Standard Access Rights)
> FILE_SHARE_READ (etc.)
> CREATE_ALWAYS (and other creation dispositions)
> FILE_FLAG_BACKUP_SEMANTICS (and other flags)
> (etc....)
>
> I've tried several of these with the define_c_var function, but with no
> success, e.g. }}}
<eucode>
>
> include dll.e
> global constant kernel32 = open_dll("kernel32.dll"),
> myMAX_PATH = define_c_var(kernel32, "MAX_PATH")
> </eucode>
{{{
> define_c_var always returns -1.
>
> Maybe I'm just confused - are constants ever visible in a .dll, or only in the
> source that created it?
> Am I limited to real VARIABLES?
>
> (The constants aren't such a big deal as the passing of struct-type varibles
> above. I can always get the values of the
> constants and define them myself, but just thought I'd mention it too in case
> anyone had an idea.)
>
> Looking forward to any help you can give. Thanks!
Jonas Temple
http://www.innovativesys.net
3. Re: DLL trouble (continued)
Sorry about that last post...butterfingers. Read on.
K. Einfeldt wrote:
> The function I'm using does actually take a struct argument, not just a
> pointer
> to a struct.
> (I tried it that way hoping the documentation was wrong, but it wasn't.) It's
> true that this
> isn't a very common occurance, but it does happen. Here's the function I'm
> currently working
> with:
> "SetFilePOinterEx" in kernel32.dll (see <a
> href="http://msdn2.microsoft.com/en-us/library/aa365542.aspx">http://msdn2.microsoft.com/en-us/library/aa365542.aspx</a>
> )
I checked the docs on this function and it's defined as:
BOOL WINAPI SetFilePointerEx(
__in HANDLE hFile,
__in LARGE_INTEGER liDistanceToMove,
__out_opt PLARGE_INTEGER lpNewFilePointer,
__in DWORD dwMoveMethod
);
The move method is described as:
dwMoveMethod
The starting point for the file pointer move. This parameter can be one of the
following values.
Value Meaning
FILE_BEGIN
0
The starting point is zero or the beginning of the file. If this flag is
specified, then the liDistanceToMove parameter is interpreted as an unsigned
value.
FILE_CURRENT
1
The start point is the current value of the file pointer.
FILE_END
2
The starting point is the current end-of-file position.
So my understanding is you pass a constant for the move method (i.e.
FILE_BEGIN). I might be missing something, but I don't see anything in MSDN that
says this parm is a struct. What you might be getting confused by is it seems
that MSDN is showing you that actual value of FILE_BEGIN, which I'm guessing is a
0. Of course you would want to define FILE_BEING somewhere in your code and pass
that instead of a literal.
HTH,
Jonas Temple
http://www.innovativesys.net
4. Re: DLL trouble (continued)
K. Einfeldt wrote:
>
> Thanks Bernie, Derek and CChris for your replies.
>
> The function I'm using does actually take a struct argument, not just a
> pointer
> to a struct.
> (I tried it that way hoping the documentation was wrong, but it wasn't.) It's
> true that this
> isn't a very common occurance, but it does happen. Here's the function I'm
> currently working
> with:
> "SetFilePOinterEx" in kernel32.dll (see <a
> href="http://msdn2.microsoft.com/en-us/library/aa365542.aspx">http://msdn2.microsoft.com/en-us/library/aa365542.aspx</a>
> )
>
> <font color="#330033">The LARGE_INTEGER is a 64-bit struct. I did manage
> </font><font color="#0000FF">to </font><font color="#330033">get the C_DOUBLE
> value </font><font color="#0000FF">to
> work, e.g. }}}
<eucode>
>
> include dll.e
> global constant kernel32 = open_dll("kernel32.dll"),
> cSetFilePointerEx = define_c_func(kernel32, "SetFilePointerEx",
> {C_UINT, -- handle of open file
> C_DOUBLE, -- bytes to move
> C_POINTER, -- pointer to new file pointer
> C_UINT}, -- dwMoveMethod (see article)
> C_UINT) -- Boolean return value
> </eucode>
{{{
> as it's the same size (64-bit), but only with the value of zero, since zero
> is encoded the same for an integer
> and a floating-point number. But for all other numbers, Euphoria will be
> taking
> the atom I use in the function
> and convert it to its floating-point equivalent, which is far different from
> the original bit-pattern.
>
> I thought about the (complicated) possibility of writing a function to
> anticipate
> this conversion and put in the
> function an atom that would convert to what I really want, but this is
> impossible
> because there's no perfect 1:1
> conversion between 64-bit integers and floating-point integers, and a lot of
> the bit encodings represent zero,
> denormals, infinity, and NaNs (not-a-number).
>
> -----
>
> re:
> > Does the define_c_var routine not work for you?
> and
> > Use define_c_var(entry_point,var_name). That will give you an address to
> > peek/poke
> at.</font></i>
>
> Maybe I'm wrong, but I'm quite sure that these (and a boat-load of other
> constants)
> are defined in kernel32.dll:
> MAX_PATH
> INVALID_HANDLE_VALUE
> ERROR_FILE_NOT_FOUND (and other error codes)
> FILE_ATTRIBUTE_COMPRESSED (and other attributes)
> GENERIC_READ (and other Generic Access Rights)
> MAXIMUM_ALLOWED
> ACCESS_SYSTEM_SECURITY
> READ_CONTROL (and other Standard Access Rights)
> FILE_SHARE_READ (etc.)
> CREATE_ALWAYS (and other creation dispositions)
> FILE_FLAG_BACKUP_SEMANTICS (and other flags)
> (etc....)
>
> I've tried several of these with the define_c_var function, but with no
> success, e.g. }}}
<eucode>
>
> include dll.e
> global constant kernel32 = open_dll("kernel32.dll"),
> myMAX_PATH = define_c_var(kernel32, "MAX_PATH")
> </eucode>
{{{
> define_c_var always returns -1.
>
> Maybe I'm just confused - are constants ever visible in a .dll, or only in the
> source that created it?
> Am I limited to real VARIABLES?
>
> (The constants aren't such a big deal as the passing of struct-type varibles
> above. I can always get the values of the
> constants and define them myself, but just thought I'd mention it too in case
> anyone had an idea.)
>
> Looking forward to any help you can give. Thanks!
It is possible to pass a 64 bit value to a DLL function. Just use 2 C_UINT
constants in the function definition. When calling the function you will have to
pass the upper and lower 32 bit values seperately. I am not certain of the order.
Constants such as MAX_PATH are not defined in any Microsoft DLL's. Microsoft
publishes these values as a part of the SDK include files but these are not
readable by a Euphoria program. Most of the values you will need are defined in
Win32Lib. A search on Google will usually locate any others required.
Larry Miller
