OS-Windows and UnifiedFFI
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 with WinWindow>>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.
2016-04-15 21:58 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
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 with WinWindow>>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?
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. 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" <nicolaihess@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI   2016-04-15 21:58 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>: 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?
2016-04-24 15:26 GMT+02:00 Torsten Bergmann <astares@gmx.de>:
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. 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" <nicolaihess@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI
2016-04-15 21:58 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
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?
Hi Nicolai,
On 25 Apr 2016, at 09:14, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-24 15:26 GMT+02:00 Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>>: 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? 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" <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> An: "Pharo Development List" <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI
2016-04-15 21:58 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:
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?
2016-04-25 9:28 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
Hi Nicolai,
On 25 Apr 2016, at 09:14, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-24 15:26 GMT+02:00 Torsten Bergmann <astares@gmx.de>:
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
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" <nicolaihess@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI
2016-04-15 21:58 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
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?
2016-04-25 10:17 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-04-25 9:28 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
Hi Nicolai,
On 25 Apr 2016, at 09:14, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-24 15:26 GMT+02:00 Torsten Bergmann <astares@gmx.de>:
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?
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" <nicolaihess@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI
2016-04-15 21:58 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
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?
participants (3)
-
Esteban Lorenzano -
Nicolai Hess -
Torsten Bergmann