Help! How to mix win32 and native os calls in code?

droidvideo · Post by **droidvideo** » Sun Jul 26, 2009 10:40 am

Hi
I have a tool that I am running under Mac version of Wine. What I am
doing is installing the tool under wine (i.e wine <path to installer
pkg.exe>) and then running it from wine.
It uses an api to capture current screen (BitBlt api). Under Mac, it
is capturing the X windows frame buffer instead of native Quartz frame
buffer. I have source code for this tool. I am thinking of replacing
Windows api for screen capture with Mac's native apis.
I am wondering if someone can point me in right direction.

a) How do I find in code if I am running under regular win32 or wine?
If wine, how do I find host OS (i.e Is it Linux or OS X?)

b) Lets say I know some how what OS the exe is running. I want to call
say LeopardCaptureScreen() on Mac. One way is to include
corresponding .h and link implicitly. But it won't compile under
windows. Any pointers on how to separate this logic in such a way that
the mac code can be compiled on Mac and be loaded under wine.

c) Any pointers on how to capture current screen on Mac OS X. I know
it should be posted under Mac forum, thought of asking here as lot of
smart people are reading this forum.

Thanks for your help
Joe

vitamin · Post by **vitamin** » Sun Jul 26, 2009 12:17 pm

droidvideo wrote:a) How do I find in code if I am running under regular win32 or wine?
If wine, how do I find host OS (i.e Is it Linux or OS X?)

Simple answer - DO NOT DO IT.

droidvideo wrote:b) Lets say I know some how what OS the exe is running. I want to call say LeopardCaptureScreen() on Mac.

Then why don't you create a native Mac application that does just that? You can do this _only_ in winelib application (line Wine's winecfg). It will _not_ work on Windows.

Also when you doing any native calls, you have to take care of proper synchronization, or you'll end-up crashing, locking up your program.

droidvideo wrote:c) Any pointers on how to capture current screen on Mac OS X?

Wrong forum, people here know mostly *NIS & win32 api. Not Mac.

austin987 · Post by **austin987** » Sun Jul 26, 2009 12:36 pm

On Sun, Jul 26, 2009 at 12:17 PM, vitamin<[email protected]> wrote:

droidvideo wrote:
a) How do I find in code if I am running under regular win32 or wine?
If wine, how do I find host OS (i.e Is it Linux or OS X?)

This question has been asked several times. Search the archives for answers.

droidvideo wrote:
c) Any pointers on how to capture current screen on Mac OS X?
Wrong forum, people here know mostly *NIS & win32 api. Not Mac.

Mac _IS_ Unix.

--
-Austin

Gert van den Berg · Post by **Gert van den Berg** » Sun Jul 26, 2009 2:39 pm

On Sun, Jul 26, 2009 at 19:35, Austin English<[email protected]> wrote:

droidvideo wrote:
c) Any pointers on how to capture current screen on Mac OS X?
Wrong forum, people here know mostly *NIS & win32 api. Not Mac.
Mac _IS_ Unix.

Yes, but the default GUI is not X11...

(And a lot of the APIs are a lot more OpenStep-like AFAIK, with Unix
APIs available for some things)

James McKenzie · Post by **James McKenzie** » Sun Jul 26, 2009 6:26 pm

Gert van den Berg wrote:

On Sun, Jul 26, 2009 at 19:35, Austin English<[email protected]> wrote:

droidvideo wrote:
Wrong forum, people here know mostly *NIS & win32 api. Not Mac.

Mac _IS_ Unix.

Yes, but the default GUI is not X11...

(And a lot of the APIs are a lot more OpenStep-like AFAIK, with Unix
APIs available for some things)

Gert, Austin and the rest:

X11 is now installed by default with Leopard. Apple recognizes that not
all applications are going to be Aqua compliant and some will never
be. This is a distinct disadvantage. BTW, it took many man-years to
get OpenOffice.org and Aqua to work well with each other. Sadly, I do
not think we have the manpower to do this for Wine. Wine will remain an
X11 application and for that reason, many Mac users will not use it.

James McKenzie

droidvideo · Post by **droidvideo** » Sun Jul 26, 2009 10:51 pm

Hi
If Wine doesn't have an api to detect Wine vs native Win32, I can check for $WINEPREFIX and use that to detect Wine. Not a big deal. I appreciate if you can point me to a better method.
What is not clear is how you can call into native .so from win32 code. I saw some interesting posts on this forum before when someone tried to include this functionality into Wine (Search for winegate.dll). I don't want to compile my whole code against winelib as my app is MFC based. Compiling MFC against winelib seems a daunting task. I don't have time and resources to pursue that route.
The tool that I am trying to run needs access to native Quartz frame buffer not the X11 frame buffer which is what wine provides. I need to call Leopard api from Win32 app. Some one pointed that it can be accomplished using wine_dlopen/wine_dlsym type calls. I couldn't find any examples.
I will look more.

I appreciate your help.

Thanks
Joe

vitamin · Post by **vitamin** » Mon Jul 27, 2009 12:43 am

Eric S. Johansson wrote:Allow me to sort of hijack this thread.

You may not.

vitamin · Post by **vitamin** » Mon Jul 27, 2009 12:50 am

droidvideo wrote:If Wine doesn't have an api to detect Wine vs native Win32, I can check for $WINEPREFIX and use that to detect Wine. Not a big deal. I appreciate if you can point me to a better method.

Again, DO NOT do it! Period and of story. You will create a defective application that will fail in the future Wine versions.

If you do not know how to check availability of some features, let user choose what platform they are running on.

droidvideo wrote:What is not clear is how you can call into native .so from win32 code.

You didn't read what I said. You can't, unless it's a winelib application (something compiled with winegcc and that can only be run under Wine).

The only possibility is to write a separate winelib dll that you can load on Wine. Then your entire program can remain win32.

Eric S. Johansson · Post by **Eric S. Johansson** » Mon Jul 27, 2009 10:27 am

vitamin wrote:

Eric S. Johansson wrote:
Allow me to sort of hijack this thread.
You may not.

ok, rethreaded even though it is the same class of problems

see: How to mix (naturally speaking) win32 and native (python) linux calls in
same application?

droidvideo · Post by **droidvideo** » Mon Jul 27, 2009 12:17 pm

How do you create separate winelib dll?
I am assuming the dll can call into native api, but I am wondering how the main win 32 app calls into this dll.

Can you point me to faq or link that talks about this?

Thanks
Joe

jorl17 · Post by **jorl17** » Mon Jul 27, 2009 7:35 pm

droidvideo wrote:How do you create separate winelib dll?
I am assuming the dll can call into native api, but I am wondering how the main win 32 app calls into this dll.

Can you point me to faq or link that talks about this?

Thanks
Joe

I wouldn't go that way, but to me it seems that if you _must_ use that pathetic alternative, you should separate all OS dependant calls into winelib dlls (google it) which you would then load, but only on the corresponding operating system, or else (if I got it correctly according to what Vitamin said), it won't be able to be run under anything other than Wine. (Correct me if wrong, please).

Why don't you write clean cross-platform code? Maybe using the classic good-old #ifdef macro? There are also many good libs out there...

If you need some documentation:

http://www.winehq.org/winelib
http://www.winehq.org/docs/winelib-guide/index
|
|=> http://www.winehq.org/docs/winelib-guide/bindlls

How does it call to this DLL? AFAIK (correct me if wrong) normally: GetProcAddress and etcetera...

Jorl17

PS: Really, please really choose a more safe option.

Eric S. Johansson · Post by **Eric S. Johansson** » Mon Jul 27, 2009 8:35 pm

jorl17 wrote:

I wouldn't go that way, but to me it seems that if you _must_ use that
pathetic alternative, you should separate all OS dependant calls into winelib
dlls (google it) which you would then load, but only on the corresponding
operating system, or else (if I got it correctly according to what Vitamin
said), it won't be able to be run under anything other than Wine. (Correct me
if wrong, please).

Why don't you write clean cross-platform code? Maybe using the classic
good-old #ifdef macro? There are also many good libs out there...

I'll be interested in hearing what you think is a good alternative architecture.
I am basing my work off of the original Windows code. It connects to the COM
interface for NaturallySpeaking and creates an extension in Python so that
grammars can activate methods with or without arguments. The difference from the
Windows version is that you need to be able to manipulate windows/inject
text/change focus etc. on the linux side. It's important to keep latency as low
as possible because it affects recognition accuracy.

Quite frankly, I would like to see a simpler solution because my hands are
broken and I don't have much typing time on daily basis. I'm pushing for better
integration with speech recognition so that I can use more of my system
hands-free and then turn my focus to speech given programming.

vitamin · Post by **vitamin** » Tue Jul 28, 2009 12:00 am

droidvideo wrote:How do you create separate winelib dll?

Take a look at any ... Wine's own dll.

droidvideo wrote:I am assuming the dll can call into native api, but I am wondering how the main win 32 app calls into this dll.

Yes, from winelib you can call any native (OS/X, POXIX, etc) function you want. Just keep in mind how much it affects everything else (locking, synchronization, memory allocations, etc).

And you call that dll from your app the same way as you would do it on real Windows - LoadLibrary, GetProcAddress, and so on.

droidvideo wrote:I'll be interested in hearing what you think is a good alternative architecture.
I am basing my work off of the original Windows code. It connects to the COM interface for NaturallySpeaking and creates an extension in Python so that grammars can activate methods with or without arguments.

If it's uses COM you can't do much with that outside of Wine. You can however add a library/interface into Wine, then use it to talk to the outside of Wine using any RPC of your liking.

One way or the other you will need to write something native, as Wine can't (and won't in the near future) "inject" anything into other X windows. It's made that way for a reason, so windows programs can only be told what to do.