Re: OS-Windows and UnifiedFFI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

Nicolai Hess-3-2


2016-05-19 8:56 GMT+02:00 Nicolai Hess <[hidden email]>:


2016-04-25 10:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2016-04-25 9:28 GMT+02:00 Esteban Lorenzano <[hidden email]>:
Hi Nicolai,

On 25 Apr 2016, at 09:14, Nicolai Hess <[hidden email]> wrote:



2016-04-24 15:26 GMT+02:00 Torsten Bergmann <[hidden email]>:
Hi Nicolai,

missed this thread - sorry. To my knowledge there was a call in NB for CreateWindow
but there was no example in opening a new window. For X-Windows there was an example
if I remember correctly.

Hi Torsten,

yes there is an "example" in NBOpenGL. On Windows, it registers and creates window for getting an opengl  context.
The code and classes for registering and creating a window are similiar to what is now in your os-windows.
I needed to define some more pool variables for some style attributes, all that is working.
What did not work is storing the hInstance attribute in the WndClass struct.

what and how it does not work?
can you paste the code?


Sure.
Load stable version of Torstens OSWindows.
Change WinProcess class>>getVMModuleHandle (it has to use HINSTANCE instead of HMODULE (or just define a new pool variable HMODULE in WinTypes))

getVMModuleHandle
    "The GetModuleHandle function retrieves a module handle for the specified module if the file has been mapped into the address space of the calling process."

    ^ self ffiCall: #( HINSTANCE GetModuleHandleA (0)) module: #Kernel32


Now create a  new WinWndClassEx and set the hInstance field:

|hInst wndClass|
hInst := WinProcess getVMModuleHandle.
wndClass := WinWndClassEx new.
wndClass hInstance: hInst.
 

-> Message not understood SmallInteger>>isExternalAddress


The equivalent code with NB that was working:

|hInst wndClass|
hInst := NativeBoostWin32 getVMModuleHandle.
wndClass := NBWndClassEx new.
wndClass hInstance: hInst.
wndClass


Any more ideas?


From my observation,

hInst := NativeBoostWin32 getVMModuleHandle.

hInst is not considered an external object, or its handle is not an
ExternalAddress, although the object is a WinHandle that is a subclass
of FFIExernalReference :-(

I am lost here,
any help appreciated.
 
 
 

cheers!
Esteban

With NBOpenGL (and non-spur resp. NativeBoost) this works.
With the new UnifiedFFI this gives an error from:

pointerAt: byteOffset put: value
    "Store a pointer object at the given byte address"
    value isExternalAddress

 

Basically I would like to add support for this into OS-Windows, yes.
Some parts are there and UFFI now has easy callbacks. Havent looked
at OSWindow yet - but I guess the goal is to create native windows as well.
Also I would like to add more support in manipulating/quering other
external windows (which can be done using the already built in support
for process and window handles).

In Win32 to create a window one has to register a window class first and
use the window class name afterwards in the CreateWindow API function.

No time to look into this this week ... but can give a try afterwards.
The WNDCLASS/WNDCLASSEX structure needs to be wrapped, RegisterClass
called and CreateWindowEx with a callback for a function to process
window messages.

Dont know how if this interferes with the VM's own processing loop ...
but we should give a try. If you catch me on Slack next week we can
try together.
 
Bye
Torsten
 

Gesendet: Sonntag, 24. April 2016 um 12:17 Uhr
Von: "Nicolai Hess" <[hidden email]>
An: "Pharo Development List" <[hidden email]>
Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI

 
 
2016-04-15 21:58 GMT+02:00 Nicolai Hess <[hidden email]>:

Hi Torsten, Esteban,
 I try to use OS-Windows (not OSWindow :) ) with latest spur VM and UnifiedFFI.As far as I can see, you (Torsten) already ported some parts to UnifiedFFI - great, thanks!
 I now try to open a new window withWinWindow>>createWindowEx ....as I took this example originally from NBOpenGL, it seems I have to define
a Window Class first, with
WinWndClassEx
This seems to work in the old NBOpenGL/NBWin32 code but not with OS-Windows
WinWndClassEx
first, NBOpenGL uses
NativeBoostWin32 getVMModuleHandle for an HModule instance
there is a similar call in OS-Windows, WinProcess getVMModuleHandle
(I needed to define a missing type, HMODULE, but that works).
 
What does not work is this part:

| hInst wndClass |
    hInst := WinProcess getVMModuleHandle.
    wndClass := WinWndClassEx new.
    wndClass hInstance: hInst.
 
FF complains about
pointerAt: byteOffset put: value
    "Store a pointer object at the given byte address"
    value isExternalAddress
 
here value is not a handle, but a small integer, and it does not define isExternalAddress
 
I tried to put the handle instead of the handles value, but this does not work either.
 
Any Idea what is missing here, I need a way to store the HMODULE handle
in the structure of the WinWNdClassEx
 
Thanks in advance.
 
Anyone?






Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

Nicolai Hess-3-2


2016-05-30 14:59 GMT+02:00 Nicolai Hess <[hidden email]>:


2016-05-19 8:56 GMT+02:00 Nicolai Hess <[hidden email]>:


2016-04-25 10:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2016-04-25 9:28 GMT+02:00 Esteban Lorenzano <[hidden email]>:
Hi Nicolai,

On 25 Apr 2016, at 09:14, Nicolai Hess <[hidden email]> wrote:



2016-04-24 15:26 GMT+02:00 Torsten Bergmann <[hidden email]>:
Hi Nicolai,

missed this thread - sorry. To my knowledge there was a call in NB for CreateWindow
but there was no example in opening a new window. For X-Windows there was an example
if I remember correctly.

Hi Torsten,

yes there is an "example" in NBOpenGL. On Windows, it registers and creates window for getting an opengl  context.
The code and classes for registering and creating a window are similiar to what is now in your os-windows.
I needed to define some more pool variables for some style attributes, all that is working.
What did not work is storing the hInstance attribute in the WndClass struct.

what and how it does not work?
can you paste the code?


Sure.
Load stable version of Torstens OSWindows.
Change WinProcess class>>getVMModuleHandle (it has to use HINSTANCE instead of HMODULE (or just define a new pool variable HMODULE in WinTypes))

getVMModuleHandle
    "The GetModuleHandle function retrieves a module handle for the specified module if the file has been mapped into the address space of the calling process."

    ^ self ffiCall: #( HINSTANCE GetModuleHandleA (0)) module: #Kernel32


Now create a  new WinWndClassEx and set the hInstance field:

|hInst wndClass|
hInst := WinProcess getVMModuleHandle.
wndClass := WinWndClassEx new.
wndClass hInstance: hInst.
 

-> Message not understood SmallInteger>>isExternalAddress


The equivalent code with NB that was working:

|hInst wndClass|
hInst := NativeBoostWin32 getVMModuleHandle.
wndClass := NBWndClassEx new.
wndClass hInstance: hInst.
wndClass


Any more ideas?


From my observation,

hInst := NativeBoostWin32 getVMModuleHandle.

hInst is not considered an external object, or its handle is not an
ExternalAddress, although the object is a WinHandle that is a subclass
of FFIExernalReference :-(

I am lost here,
any help appreciated.


Please.

(I do undestand that a winhandle is only a number and not a external memory.
But how to handle this "handles" when passing to a external function ?)
 
 
 
 

cheers!
Esteban

With NBOpenGL (and non-spur resp. NativeBoost) this works.
With the new UnifiedFFI this gives an error from:

pointerAt: byteOffset put: value
    "Store a pointer object at the given byte address"
    value isExternalAddress

 

Basically I would like to add support for this into OS-Windows, yes.
Some parts are there and UFFI now has easy callbacks. Havent looked
at OSWindow yet - but I guess the goal is to create native windows as well.
Also I would like to add more support in manipulating/quering other
external windows (which can be done using the already built in support
for process and window handles).

In Win32 to create a window one has to register a window class first and
use the window class name afterwards in the CreateWindow API function.

No time to look into this this week ... but can give a try afterwards.
The WNDCLASS/WNDCLASSEX structure needs to be wrapped, RegisterClass
called and CreateWindowEx with a callback for a function to process
window messages.

Dont know how if this interferes with the VM's own processing loop ...
but we should give a try. If you catch me on Slack next week we can
try together.
 
Bye
Torsten
 

Gesendet: Sonntag, 24. April 2016 um 12:17 Uhr
Von: "Nicolai Hess" <[hidden email]>
An: "Pharo Development List" <[hidden email]>
Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI

 
 
2016-04-15 21:58 GMT+02:00 Nicolai Hess <[hidden email]>:

Hi Torsten, Esteban,
 I try to use OS-Windows (not OSWindow :) ) with latest spur VM and UnifiedFFI.As far as I can see, you (Torsten) already ported some parts to UnifiedFFI - great, thanks!
 I now try to open a new window withWinWindow>>createWindowEx ....as I took this example originally from NBOpenGL, it seems I have to define
a Window Class first, with
WinWndClassEx
This seems to work in the old NBOpenGL/NBWin32 code but not with OS-Windows
WinWndClassEx
first, NBOpenGL uses
NativeBoostWin32 getVMModuleHandle for an HModule instance
there is a similar call in OS-Windows, WinProcess getVMModuleHandle
(I needed to define a missing type, HMODULE, but that works).
 
What does not work is this part:

| hInst wndClass |
    hInst := WinProcess getVMModuleHandle.
    wndClass := WinWndClassEx new.
    wndClass hInstance: hInst.
 
FF complains about
pointerAt: byteOffset put: value
    "Store a pointer object at the given byte address"
    value isExternalAddress
 
here value is not a handle, but a small integer, and it does not define isExternalAddress
 
I tried to put the handle instead of the handles value, but this does not work either.
 
Any Idea what is missing here, I need a way to store the HMODULE handle
in the structure of the WinWNdClassEx
 
Thanks in advance.
 
Anyone?







Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

EstebanLM

On 24 Jun 2016, at 09:26, Nicolai Hess <[hidden email]> wrote:



2016-05-30 14:59 GMT+02:00 Nicolai Hess <[hidden email]>:


2016-05-19 8:56 GMT+02:00 Nicolai Hess <[hidden email]>:


2016-04-25 10:17 GMT+02:00 Nicolai Hess <[hidden email]>:


2016-04-25 9:28 GMT+02:00 Esteban Lorenzano <[hidden email]>:
Hi Nicolai,

On 25 Apr 2016, at 09:14, Nicolai Hess <[hidden email]> wrote:



2016-04-24 15:26 GMT+02:00 Torsten Bergmann <[hidden email]>:
Hi Nicolai,

missed this thread - sorry. To my knowledge there was a call in NB for CreateWindow
but there was no example in opening a new window. For X-Windows there was an example
if I remember correctly.

Hi Torsten,

yes there is an "example" in NBOpenGL. On Windows, it registers and creates window for getting an opengl  context.
The code and classes for registering and creating a window are similiar to what is now in your os-windows.
I needed to define some more pool variables for some style attributes, all that is working.
What did not work is storing the hInstance attribute in the WndClass struct.

what and how it does not work?
can you paste the code?


Sure.
Load stable version of Torstens OSWindows.
Change WinProcess class>>getVMModuleHandle (it has to use HINSTANCE instead of HMODULE (or just define a new pool variable HMODULE in WinTypes))

getVMModuleHandle
    "The GetModuleHandle function retrieves a module handle for the specified module if the file has been mapped into the address space of the calling process."

    ^ self ffiCall: #( HINSTANCE GetModuleHandleA (0)) module: #Kernel32


Now create a  new WinWndClassEx and set the hInstance field:

|hInst wndClass|
hInst := WinProcess getVMModuleHandle.
wndClass := WinWndClassEx new.
wndClass hInstance: hInst.
 

-> Message not understood SmallInteger>>isExternalAddress


The equivalent code with NB that was working:

|hInst wndClass|
hInst := NativeBoostWin32 getVMModuleHandle.
wndClass := NBWndClassEx new.
wndClass hInstance: hInst.
wndClass


Any more ideas?


From my observation,

hInst := NativeBoostWin32 getVMModuleHandle.

hInst is not considered an external object, or its handle is not an
ExternalAddress, although the object is a WinHandle that is a subclass
of FFIExernalReference :-(

I am lost here,
any help appreciated.


Please.

(I do undestand that a winhandle is only a number and not a external memory.
But how to handle this "handles" when passing to a external function ?)

I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 
UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]]

is there anything I’m missing?

Esteban


 
 
 
 

cheers!
Esteban

With NBOpenGL (and non-spur resp. NativeBoost) this works.
With the new UnifiedFFI this gives an error from:

pointerAt: byteOffset put: value
    "Store a pointer object at the given byte address"
    value isExternalAddress

 

Basically I would like to add support for this into OS-Windows, yes.
Some parts are there and UFFI now has easy callbacks. Havent looked
at OSWindow yet - but I guess the goal is to create native windows as well.
Also I would like to add more support in manipulating/quering other
external windows (which can be done using the already built in support
for process and window handles).

In Win32 to create a window one has to register a window class first and
use the window class name afterwards in the CreateWindow API function.

No time to look into this this week ... but can give a try afterwards.
The WNDCLASS/WNDCLASSEX structure needs to be wrapped, RegisterClass
called and CreateWindowEx with a callback for a function to process
window messages.

Dont know how if this interferes with the VM's own processing loop ...
but we should give a try. If you catch me on Slack next week we can
try together.
 
Bye
Torsten
 

Gesendet: Sonntag, 24. April 2016 um 12:17 Uhr
Von: "Nicolai Hess" <[hidden email]>
An: "Pharo Development List" <[hidden email]>
Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI

 
 
2016-04-15 21:58 GMT+02:00 Nicolai Hess <[hidden email]>:

Hi Torsten, Esteban,
 I try to use OS-Windows (not OSWindow :) ) with latest spur VM and UnifiedFFI.As far as I can see, you (Torsten) already ported some parts to UnifiedFFI - great, thanks!
 I now try to open a new window withWinWindow>>createWindowEx ....as I took this example originally from NBOpenGL, it seems I have to define
a Window Class first, with
WinWndClassEx
This seems to work in the old NBOpenGL/NBWin32 code but not with OS-Windows
WinWndClassEx
first, NBOpenGL uses
NativeBoostWin32 getVMModuleHandle for an HModule instance
there is a similar call in OS-Windows, WinProcess getVMModuleHandle
(I needed to define a missing type, HMODULE, but that works).
 
What does not work is this part:

| hInst wndClass |
    hInst := WinProcess getVMModuleHandle.
    wndClass := WinWndClassEx new.
    wndClass hInstance: hInst.
 
FF complains about
pointerAt: byteOffset put: value
    "Store a pointer object at the given byte address"
    value isExternalAddress
 
here value is not a handle, but a small integer, and it does not define isExternalAddress
 
I tried to put the handle instead of the handles value, but this does not work either.
 
Any Idea what is missing here, I need a way to store the HMODULE handle
in the structure of the WinWNdClassEx
 
Thanks in advance.
 
Anyone?








Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

Nicolai Hess-3-2


I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 

Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working.

UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]]

is there anything I’m missing?

I don't know what else should I do, I already posted the example.
The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work.
Yes, maybe I don't know enough about ffi for this type of the function argument passing.

(actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context).
So if this *is* already working, I need to look what I have done wrong).

thanks for your response.
nicolai

 

Esteban




Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

EstebanLM

On 24 Jun 2016, at 09:53, Nicolai Hess <[hidden email]> wrote:



I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 

Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working.

UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]]

is there anything I’m missing?

I don't know what else should I do, I already posted the example.
The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work.
Yes, maybe I don't know enough about ffi for this type of the function argument passing.

the example is a simplification, you cannot put both definition and call in same method… find attached a working example of what you want.





(actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context).
So if this *is* already working, I need to look what I have done wrong).

thanks for your response.
nicolai

 

Esteban






HandleExample.st (929 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

Nicolai Hess-3-2


2016-06-24 14:05 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 24 Jun 2016, at 09:53, Nicolai Hess <[hidden email]> wrote:



I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 

Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working.

UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]]

is there anything I’m missing?

I don't know what else should I do, I already posted the example.
The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work.
Yes, maybe I don't know enough about ffi for this type of the function argument passing.

the example is a simplification, you cannot put both definition and call in same method… find attached a working example of what you want.


Thank you!
 





(actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context).
So if this *is* already working, I need to look what I have done wrong).

thanks for your response.
nicolai

 

Esteban







Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

EstebanLM
… and I enhanced the example to not induce to confusion anymore :)

Esteban

On 24 Jun 2016, at 14:27, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:05 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 24 Jun 2016, at 09:53, Nicolai Hess <[hidden email]> wrote:



I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 

Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working. 

UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]] 

is there anything I’m missing?

I don't know what else should I do, I already posted the example.
The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work.
Yes, maybe I don't know enough about ffi for this type of the function argument passing.

the example is a simplification, you cannot put both definition and call in same method… find attached a working example of what you want.


Thank you!
 





(actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context).
So if this *is* already working, I need to look what I have done wrong).

thanks for your response.
nicolai

 

Esteban

Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

Nicolai Hess-3-2


2016-06-24 14:32 GMT+02:00 Esteban Lorenzano <[hidden email]>:
… and I enhanced the example to not induce to confusion anymore :)

Esteban

Sorry, I must be stupid, it still does not work ( and it actually looks the same as with the existing WinHandle type).

 

On 24 Jun 2016, at 14:27, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:05 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 24 Jun 2016, at 09:53, Nicolai Hess <[hidden email]> wrote:



I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 

Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working. 

UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]] 

is there anything I’m missing?

I don't know what else should I do, I already posted the example.
The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work.
Yes, maybe I don't know enough about ffi for this type of the function argument passing.

the example is a simplification, you cannot put both definition and call in same method… find attached a working example of what you want.


Thank you!
 





(actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context).
So if this *is* already working, I need to look what I have done wrong).

thanks for your response.
nicolai

 

Esteban


Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

EstebanLM

On 24 Jun 2016, at 14:40, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:32 GMT+02:00 Esteban Lorenzano <[hidden email]>:
… and I enhanced the example to not induce to confusion anymore :)

Esteban

Sorry, I must be stupid, it still does not work ( and it actually looks the same as with the existing WinHandle type).

well, that I don’t know… for me it works, I tested it in Win10 and it was fine. 
What exactly are you trying to do?

Esteban


 

On 24 Jun 2016, at 14:27, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:05 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 24 Jun 2016, at 09:53, Nicolai Hess <[hidden email]> wrote:



I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 

Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working. 

UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]] 

is there anything I’m missing?

I don't know what else should I do, I already posted the example.
The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work.
Yes, maybe I don't know enough about ffi for this type of the function argument passing.

the example is a simplification, you cannot put both definition and call in same method… find attached a working example of what you want.


Thank you!
 





(actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context).
So if this *is* already working, I need to look what I have done wrong).

thanks for your response.
nicolai

 

Esteban



Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

EstebanLM
In reply to this post by Nicolai Hess-3-2
ah, and which VM are you using?

On 24 Jun 2016, at 14:40, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:32 GMT+02:00 Esteban Lorenzano <[hidden email]>:
… and I enhanced the example to not induce to confusion anymore :)

Esteban

Sorry, I must be stupid, it still does not work ( and it actually looks the same as with the existing WinHandle type).

 

On 24 Jun 2016, at 14:27, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:05 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 24 Jun 2016, at 09:53, Nicolai Hess <[hidden email]> wrote:



I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 

Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working. 

UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]] 

is there anything I’m missing?

I don't know what else should I do, I already posted the example.
The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work.
Yes, maybe I don't know enough about ffi for this type of the function argument passing.

the example is a simplification, you cannot put both definition and call in same method… find attached a working example of what you want.


Thank you!
 





(actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context).
So if this *is* already working, I need to look what I have done wrong).

thanks for your response.
nicolai

 

Esteban



Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

Nicolai Hess-3-2
In reply to this post by EstebanLM


2016-06-24 14:52 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 24 Jun 2016, at 14:40, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:32 GMT+02:00 Esteban Lorenzano <[hidden email]>:
… and I enhanced the example to not induce to confusion anymore :)

Esteban

Sorry, I must be stupid, it still does not work ( and it actually looks the same as with the existing WinHandle type).

well, that I don’t know… for me it works, I tested it in Win10 and it was fine. 

What was fine?
 
What exactly are you trying to do?

As I wrote, I try to get the vmmodule handle (WinProcess getVMModuleHandle) and assign it to the hInstance field of a WinWndClassEx,
getting the vm module handle works, (both, if I use the existing WinHandle type or (like you) a direct FFIConstantHandle).

But assigning this value to the hInstance field always gives a DNU
MessageNotUnderstood: SmallInteger>>isExternalAddress

I do understant that a WinHandle is not an external (memory) resource and has no external address.
I just don't undestand how to pass this type of arguments.
 

Esteban


 

On 24 Jun 2016, at 14:27, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:05 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 24 Jun 2016, at 09:53, Nicolai Hess <[hidden email]> wrote:



I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 

Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working. 

UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]] 

is there anything I’m missing?

I don't know what else should I do, I already posted the example.
The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work.
Yes, maybe I don't know enough about ffi for this type of the function argument passing.

the example is a simplification, you cannot put both definition and call in same method… find attached a working example of what you want.


Thank you!
 





(actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context).
So if this *is* already working, I need to look what I have done wrong).

thanks for your response.
nicolai

 

Esteban




Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

EstebanLM
if you send me the code, I can take a look.

On 24 Jun 2016, at 15:06, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:52 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 24 Jun 2016, at 14:40, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:32 GMT+02:00 Esteban Lorenzano <[hidden email]>:
… and I enhanced the example to not induce to confusion anymore :)

Esteban

Sorry, I must be stupid, it still does not work ( and it actually looks the same as with the existing WinHandle type).

well, that I don’t know… for me it works, I tested it in Win10 and it was fine. 

What was fine?
 
What exactly are you trying to do?

As I wrote, I try to get the vmmodule handle (WinProcess getVMModuleHandle) and assign it to the hInstance field of a WinWndClassEx,
getting the vm module handle works, (both, if I use the existing WinHandle type or (like you) a direct FFIConstantHandle).

But assigning this value to the hInstance field always gives a DNU
MessageNotUnderstood: SmallInteger>>isExternalAddress

I do understant that a WinHandle is not an external (memory) resource and has no external address.
I just don't undestand how to pass this type of arguments.
 

Esteban


 

On 24 Jun 2016, at 14:27, Nicolai Hess <[hidden email]> wrote:



2016-06-24 14:05 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 24 Jun 2016, at 09:53, Nicolai Hess <[hidden email]> wrote:



I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 

Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working. 

UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]] 

is there anything I’m missing?

I don't know what else should I do, I already posted the example.
The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work.
Yes, maybe I don't know enough about ffi for this type of the function argument passing.

the example is a simplification, you cannot put both definition and call in same method… find attached a working example of what you want.


Thank you!
 





(actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context).
So if this *is* already working, I need to look what I have done wrong).

thanks for your response.
nicolai

 

Esteban





Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

Nicolai Hess-3-2


2016-06-24 16:03 GMT+02:00 Esteban Lorenzano <[hidden email]>:
if you send me the code, I can take a look.


Sorry if this sounds rude, but
did you actually read my mail, I mean the first one.

If you don't have the time to look at this, it is ok. I will just try to find it out myself, or maybe torsten has an idea.
No problem.

I already posted the code multiple times. There is no code I could send. It is all in the image (+ the OSWindow) project.

I'll try it again.

OS: Windows
- take a fresh
- load (from catalog browser) OSWindow

- execute this

| hInst wndClass |
 hInst := WinProcess getVMModuleHandle.
 wndClass := WinWndClassEx new.
 wndClass hInstance: hInst.

Error :
Unable to resolve external type: HMODULE

OK, getVMModuleHandle expects a HMODULE type
We need to define a missing type, HMODULE, but that works (just like all the other H-WinHandle-Types).

Now execute it again:
New error:
"MessageNotUnderstood: SmallInteger>>isExternalAddress"

The question is:

Any Idea what is missing here, I need a way to store the HMODULE handle
in the structure of the WinWNdClassEx

Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

EstebanLM

On 24 Jun 2016, at 16:43, Nicolai Hess <[hidden email]> wrote:



2016-06-24 16:03 GMT+02:00 Esteban Lorenzano <[hidden email]>:
if you send me the code, I can take a look.

Sorry if this sounds rude, but
did you actually read my mail, I mean the first one.

well… after search, it was from 25 apr… and my client didn’t show it to me (because I removed it, to clean)… and it folded the quoted so yes, I read it… like a month ago :)


If you don't have the time to look at this, it is ok. I will just try to find it out myself, or maybe torsten has an idea.
No problem.

well, but I’m particularly interested in UFFI, since is my new toy :)
and seriously, I want to make him really solid, so I jump in whenever I see a problem, even if I’m doing something different (merging pharo-vm with os-vm, now). 

Anyway, I see the error: WinWndClassEx is generated with bad mapping… this is fixed in new versions of UFFI so you need to regenerate the fields:

WinWndClassEx rebuildFieldAccessors. (Torsten needs to 

but then… I spotted a bug, because FFIConstantHandle>>value is not defined so you will still have an error :)

anyway, I updated both, OSWindow and UFFI so if I you load bleedingEdge of both, you will see something like this: 



I already posted the code multiple times. There is no code I could send. It is all in the image (+ the OSWindow) project.

I'll try it again.

OS: Windows
- take a fresh
- load (from catalog browser) OSWindow

- execute this

| hInst wndClass |
 hInst := WinProcess getVMModuleHandle.
 wndClass := WinWndClassEx new.
 wndClass hInstance: hInst.

Error :
Unable to resolve external type: HMODULE

OK, getVMModuleHandle expects a HMODULE type
We need to define a missing type, HMODULE, but that works (just like all the other H-WinHandle-Types).

Now execute it again:
New error:
"MessageNotUnderstood: SmallInteger>>isExternalAddress"

The question is:

Any Idea what is missing here, I need a way to store the HMODULE handle
in the structure of the WinWNdClassEx

Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

Nicolai Hess-3-2
Yes! That is much better,

thanks

2016-06-24 17:16 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 24 Jun 2016, at 16:43, Nicolai Hess <[hidden email]> wrote:



2016-06-24 16:03 GMT+02:00 Esteban Lorenzano <[hidden email]>:
if you send me the code, I can take a look.

Sorry if this sounds rude, but
did you actually read my mail, I mean the first one.

well… after search, it was from 25 apr… and my client didn’t show it to me (because I removed it, to clean)… and it folded the quoted so yes, I read it… like a month ago :)


If you don't have the time to look at this, it is ok. I will just try to find it out myself, or maybe torsten has an idea.
No problem.

well, but I’m particularly interested in UFFI, since is my new toy :)
and seriously, I want to make him really solid, so I jump in whenever I see a problem, even if I’m doing something different (merging pharo-vm with os-vm, now). 

Anyway, I see the error: WinWndClassEx is generated with bad mapping… this is fixed in new versions of UFFI so you need to regenerate the fields:

WinWndClassEx rebuildFieldAccessors. (Torsten needs to 

but then… I spotted a bug, because FFIConstantHandle>>value is not defined so you will still have an error :)

anyway, I updated both, OSWindow and UFFI so if I you load bleedingEdge of both, you will see something like this: 



I already posted the code multiple times. There is no code I could send. It is all in the image (+ the OSWindow) project.

I'll try it again.

OS: Windows
- take a fresh
- load (from catalog browser) OSWindow

- execute this

| hInst wndClass |
 hInst := WinProcess getVMModuleHandle.
 wndClass := WinWndClassEx new.
 wndClass hInstance: hInst.

Error :
Unable to resolve external type: HMODULE

OK, getVMModuleHandle expects a HMODULE type
We need to define a missing type, HMODULE, but that works (just like all the other H-WinHandle-Types).

Now execute it again:
New error:
"MessageNotUnderstood: SmallInteger>>isExternalAddress"

The question is:

Any Idea what is missing here, I need a way to store the HMODULE handle
in the structure of the WinWNdClassEx


Reply | Threaded
Open this post in threaded view
|

Re: OS-Windows and UnifiedFFI

stepharo
In reply to this post by EstebanLM

Example in chapter please :)


Le 24/6/16 à 14:05, Esteban Lorenzano a écrit :

On 24 Jun 2016, at 09:53, Nicolai Hess <[hidden email]> wrote:



I’m sorry… I do not understand. This is solved in UFFI since some months, and Torsten’s OSWindow uses it. 

Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working.

UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: 

I represent a constant HANDLE, as described in  *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).aspx*

A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory).

Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-processes.html*.

Example: 
[[[
HWND := #FFIConstantHandle.
self ffiCall: #(HWND GetActiveWindow())
]]]

is there anything I’m missing?

I don't know what else should I do, I already posted the example.
The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work.
Yes, maybe I don't know enough about ffi for this type of the function argument passing.

the example is a simplification, you cannot put both definition and call in same method… find attached a working example of what you want.






(actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context).
So if this *is* already working, I need to look what I have done wrong).

thanks for your response.
nicolai

 

Esteban