November 2005 - Wine-devel - list.winehq.org

hid.dll support
by Phil Lodwick 01 Nov '05

01 Nov '05

Greetings, I was introduced to Wine a few months ago and ran into a problem with an application I wanted to use. This application makes use of setupapi.dll and hid.dll to communicate with a USB HID class device. I quickly determined that in this case using native dlls was not an option and created an implementation of hid.dll. This solution has worked fine for me. >From what I have gathered from monitoring the Wine community, making something work for yourself is easy -- getting a general fix into Wine for everybody to use, not so easy :-) There is much work that needs to be done before I attempt to submit my first patch. Please bear with me as I no doubt ask newbie/dumb questions. I would like to start with what I consider my most troubling solution. My gut tells me there must be a better way, but if there is, it is not obvious to me. >From MSDN: "To communicate with the device, call the SetupDiGetDeviceInterfaceDetail function. This function returns device information in an SP_DEVICE_INTERFACE_DETAIL_DATA structure. The DevicePath member provides the symbolic link name, which can be used in the CreateFile function to access the device." On Windows this DevicePath takes the form: \\?\hid#vid_0c27&pid_3bfa#6&11440ca5&0&0000#{4d1e55b2-f16f-11cf-88cb-00111100 0030} Obviously, if we were to call Wine's implementation of CreateFile with this path, we would not be opening the correct file to communicate with the device. My solution is to have SetupDiGetDeivceInterfaceDetail return a special escape string that we can escape in CreateFile to indicate we are really talking about getting a file descriptor for an open USB HID device. There already seems to be precedence in CreateFile for this type of escape mechanism. Currently it appears to be checking for: \\??\\pipe\\ \\??\\MAILSLOT\\ Does my solution for adding a third special escape sequence (\\??\\HID\\) seem acceptable? If this is the wrong approach, has there been anybody who has thought about this problem and what the correct approach would be? Thanks, Phil

2 1

Re: comctl32: MSVC portability fix
by Steven Edwards 01 Nov '05

01 Nov '05

Hi Martin, On 11/1/05, Martin Fuchs <martin-fuchs(a)gmx.net> wrote: > +#include "config.h" > +#include "wine/port.h" /* strncasecmp */ Please don't add the comment after the include statement here. Its really not needed and I doubt Alexandre will merge it. Thanks Steven

1 0

wine for two, please.
by wino＠piments.com 01 Nov '05

01 Nov '05

Hi, I dont know much about the message queue works on Wine but wondered if there was means of running two progams in the same context on wine in such a way that they use the same message queue and can therefore potencially interact. As I understand it, running two instance of command line wine is more analogous to having two different computers running each app under windows. My goal is getting NatSpeak dictated text messages freed from the confines of the wine instance of the app. This would seem to be one approach if wine can run more than one process at a time. TIA.

4 5

Calling PE DLLs
by Daniel Stodden 01 Nov '05

01 Nov '05

hi all. i'm stuck. like probably many others before me, i've got a native w32 dll which i would like to hook into on a linux box. no source code available. the case is almost identical to http://www.winehq.com/hypermail/wine-devel/2003/12/index.html#231 though, there's not much application code yet, except a small test program written by myself, currently only meant to call a single function on the dll. so, winemaker doesn't spit out anything usable, and there seems to be no official documentation on how to use winebuild here. the program is called test.c, calling symbols from a vendor-supplied header file. created test.o through winegcc: winegcc -Wall -O2 -I. -c -o test.o test.c let's call the library vendor.dll again. i've played with winedump, finally got a vendor.dll.spec. i'm calling winebuild to get a .def as follows: winebuild --def -E vendor.dll.spec -o libvendor.def then, one of my better guesses on how to proceed seemed to be: winebuild --dll -fPIC -E vendor.dll.spec -L. -lvendor test.o -o libmxmapi32.dll.s the assembler code looks reasonable. though, linking fails with duplicate symbols: winegcc test.o libmxmapi32.dll.o -o test [..] : multiple definition of `__wine_spec_nt_header' : multiple definition of `__wine_spec_file_name' i'm aware that i could probably avoid all of this by just using LoadLibrary() and resolving the symbols at runtime. otoh, the approach above is potentially simpler, if i just knew how. :) could someone please enlighten me? what am i doing wrong? thanks, daniel -- Daniel Stodden LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation Institut für Informatik der TU München D-85748 Garching http://www.lrr.in.tum.de/~stodden mailto:stodden(a)cs.tum.edu PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B

1 0

program works under winedbg but not under wine
by Matheus Izvekov 01 Nov '05

01 Nov '05

Hi all This program works (with some small issues, but not really a problem for me right now) if i run it with winedbg and just type cont, but if i run it with wine, it will freeze somewhere before it creates the main window. The program is actually coded by me, and i can give the exe or the source if anyone is interested. its a very small program (17kb uncompressed), and it just uses some common dlls (no CRT). the source is very small as well. Thanks in advance

2 1

UnixFolder_IShellFOlder used instead of SHELL32_IShellFolder
by Vitaliy Margolen 01 Nov '05

01 Nov '05

For some reason now UnixFolder_IShellFOlder is used in some cases where SHELL32_IShellFolder should of been used instead. If you look at the sheel32/test/shlfolder.c test_EnumObjects_and_CompareIDs it should use the real IShellFolder. But for some reason it's being replaced by UnixFolder_IShellFOlder. Any ideas why this is happening? I thought that it should be it's own shell name space (different ID)? This could be a main cause for all the problems people having with browsing files. As now you can "escape" to the root (/) dir. That should not be possible for windows programs! -- Best regards, Vitaliy

2 1

Re: Wine on Solaris?
by Rob D 01 Nov '05

01 Nov '05

At 02:32 AM 11/1/2005, Molle Bestefich wrote: >Rob D wrote: > > Solaris is like the red-headed step child of the Wine world. > >What an odd remark.. What does that mean? After perusing Robert Lunnons patchkit for hints to resolve build issues, it would appear that most of the issues that keep Wine from building on Solaris are known, but for whatever reason, do not get accepted into the main stream source. I know that Solaris does several things quite different than most *nix implementations, but perhaps due to the limited use of Solaris, the powers that be resist putting in extra tests to support a small set of users. That is just my quickly arrived at opinion based on a very short exposure to the environment, Sorry if I am misunderstanding the issues. Rob Done

4 4

compile wine with icc
by Tomas Carnecky 01 Nov '05

01 Nov '05

anyone already tried that? I'm getting some errors when compiling wine which I was able to fix, but World of Warcraft won't start... Will icc be supported at some time in the furure? tom

4 10

Need some help debugging listview (Process Explorer)
by Paul Vriens 01 Nov '05

01 Nov '05

Hi, I've managed to reliably crash Wine (CVS) when using Process Explorer when using some listviews. If I start Process Explorer I have two listviews one containing process-names and such, the other the dll's belonging to that process. The 'names' one has 3 columns, the 'dll' one has 5 (in my case). When I now select one of the dll's and look for the strings in that dll (one of the options in the right-click menu) I see a new listview with 1 column. At some point (i guess moving the mouse between the 2 windows, speeds up the crash) I get: 000c:fixme:listview:LISTVIEW_GetColumnInfo nSubItem : 1, DPA_GetPtrCount(infoPtr->hdpaColumns) : 1 wine-pthread: listview.c:1388: LISTVIEW_GetColumnInfo: Assertion `nSubItem >= 0 && nSubItem < (*(INT*)(infoPtr->hdpaColumns))' failed. (the fixme is my doing). It seems that listview is mixing up things (a conclusion/guess on my side). The listview with 1 column consist of 34856 items: 000c:trace:listview:LISTVIEW_GetItemT (lpLVItem={iItem=34856, iSubItem=0, pszText=L"WINE_1.0", cchTextMax=512}, isW=1) but that doesn't seem to be an issue. Any hints/tips/tricks ? Cheers, Paul.

1 0

Where is Kernel32.dll ?
by Informações 01 Nov '05

01 Nov '05

Hey all, I posted this message at the tail of another thread but I think it lost its visibility, as the subject was quite different. Here it goes again: I was performing some naive tests on my Windows box and got stuck on something that looks quite dumb... I just can't find the KERNEL32.DLL library that I expected to be inside the downloadable "wine-dlls-0.9-mingw.zip" package. ;.( Can anyone confirm me if this DLL has successfully being build on Windows using MingW ? If so, where should I look for it ? If not, which were the caveats ? Just another piece of information: I extracted the contents of this package in a temporary directory and placed the notepad.exe executable along with a dummy notepad.exe.local file inside the same directory. When I try to run notepad, I have an error message that reads something like: "It wasn't possible to find the entry-point for the procedure wine_get_unix_file_name in dynamic library kernel32.dll" The message is written in portuguese, and this is the best translation that I was able to do. It looks like any other Wine library tries to call a procedure from the Wine kernel32,dll but ends up calling this procedure on the native kernel32.dll. Is that right ? Well... I really need the functionality implemented by the Wine kernel32.dll available on Windows and I'm willing to contribute to have this done. Any help is greatly appreciated. FLu-X

3 2