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

Calling PE DLLs
by Daniel Stodden 02 Nov '05

02 Nov '05

hi all. sorry in case this email will get delivered twice to the list. i subscribed yesterday an promptly used the wrong mail address to post. so here i post again. i'm stuck at the process of loading PE dlls. like some 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, using winemaker does not seem to 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 libvendor.dll.s the assembler code looks reasonable. though, linking fails with duplicate symbols: winegcc test.o libvendor.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

3 4

[d3d8] FillVertexShaderInputARBHW wrong color order for D3DCOLOR?
by Christoph Frick 02 Nov '05

02 Nov '05

hiho, i encountered the following problem with Live For Speed [1]: once i setup my car and choose a color for it red and blue are swaped. also i got a FIXME there from: dlls/d3d8/vshaderdeclaration.c:675 (the case for D3DVSDT_D3DCOLOR). so i tried various things to put data in the hardware, but none worked - most of the time the car/game had simply extreme strange colors. so my approach (the obvious: get data from curPos, honouring skip and put it in my own 4 byte array, then call the glVertexAttribPointerARB with my array and skip=0) does not work at all - especially because i really dont have any clue about vertex shading at all, i guess. my assumtion: opengl takes for the 4 bytes RGBA->XYZW and D3DCOLOR is BGRA->XYZW (thats also what the software branch of this method wants). any ideas? -- cu

2 1

Re: Need some help debugging listview (Process Explorer)
by Dimi Paun 02 Nov '05

02 Nov '05

On Wed, 2005-11-02 at 08:26 +0100, Paul Vriens wrote: > Ok, there we go (i've started winedbg or I'm not getting to the wine > debugger, the bt is however the same as already printed): Good. Can you also send me your version of listview.c and the output of a run with +listview? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 3

Resource file and linking C++ project using winelib
by Brenda y Sergio 02 Nov '05

02 Nov '05

Hi all, I am porting an application from windows to linux (Miranda IM, a multiprotocol IM program). I have just run into one problem: the file gets compiled and runs, but the resources (icons, dialogs, images) do not seem to be working (i.e.: they are simply not shown). Sometimes, I am getting this message in the console each time I try to open certain dialogs: err:win:CreateWindowExA bad class name "??????ly t\x10" Other, a different dialog (and not present in my plugin, just one from the main application) gets opened. What I am doing in fact is making some of the application's plugins and I am getting this problem only with two plugins that were developed in C++. I have succesfully compiled and made work the ones that were written in C. My question: is this problem related to generating / linking to the .res file? Is there a way of solving it? Did anyone here have the same problem and manage to make it work? Has anyone here tried to link a C++ project using winelib and did not experience this problem? Thank you very much. I am really lost and your help will be highly appreciated. Sergio.

4 3

Re: Shell32 File Property Dialog
by Andreas Mohr 02 Nov '05

02 Nov '05

Hi, On Sat, Oct 29, 2005 at 08:59:51PM +0200, Johannes Anderwald wrote: > This patch adds file property dialog to shell32 > + LTEXT "Type of file:", 14004, 10, 30, 50, 10 Space missing?? > + LTEXT "Modied: ", 14016, 10, 90, 45, 10 "Modified: " > FIXME("Unhandled Verb %xl\n",LOWORD(lpcmi->lpVerb)); What kind of format specifier is that supposed to be? I don't know that one... Maybe use %p instead? (or %lx??) > HWND hDlgCtrl = GetDlgItem(hwndDlg, 14005); > > if (filext == NULL || hDlgCtrl == NULL) > return FALSE; Wasteful invocation of GetDlgItem() here, although the failure check is a bit "prettier" that way... > result = RegEnumValueW(hKey,0, name, &lname, NULL, NULL, (LPBYTE)value, &lvalue); space missing after hkey ;) > BOOL > SHFileGeneralGetFileTimeString(LPFILETIME lpFileTime, WCHAR * lpResult) > { > FILETIME ft; > SYSTEMTIME dt; > WORD wYear; > WCHAR wFormat[] = {'%','0','2','d','/','%','0','2','d','/','%','0','4','d',' ',' ','%','0','2','d',':','%','0','2','u',0}; static const WCHAR > TRACE("result %s \n",debug_strw(lpResult)); Superfluous space. > WARN("failed to open file \n"); > WARN("GetFileTime failed \n"); > TRACE("hDlgCtrl %x text %s \n",hDlgCtrl, debug_strw(resultstr)); > WARN("failed to open file \n"); > WARN("GetFileSize failed \n"); Dito (I prefer Wine to be smaller rather than the error message to be a bit "more readable" ;). (and probably more instances of superfluous space in this patch) > if (GetFileSize(hFile, NULL) == 0xFFFFFFFF) > { > CloseHandle(hFile); > return FALSE; > } > > dwFileLo = GetFileSize(hFile, &dwFileHi); > CloseHandle(hFile); > > if (dwFileLo == 0xFFFFFFFF && GetLastError() != NO_ERROR) > return FALSE; This whole check sounds very weird. Why are you checking with NULL hiword when there might be a > 4GB file? (and to make it worse, even one with e.g. a size of 0x12345678FFFFFFFF !!!!!!) And directly after that even doing a full large file check **again**? Not to mention that you're not using the INVALID_FILE_SIZE macro that I really, really think should be used since it's been created *exactly* for this purpose (and for the even better purpose of *never* managing to write/edit/delete a 0xFFFFFF or 0xFFFFFFF instead...) > FIXME("directory / drive resources dont exist yet \n"); ' missing ;) Sorry for this VERY anal review (it's got to be my most thorough WP review), and thanks very much for this large patch :) Andreas -- GNU/Linux. It's not the software that's free, it's you.

2 2

Re: [User] Fix clip cursor handling on resolution change
by Alexandre Julliard 02 Nov '05

02 Nov '05

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > @@ -173,6 +174,13 @@ > /* Initialize system colors and metrics */ > SYSPARAMS_Init(); > > + /* Now that system metrics are set-up, we can initialize the clip rectangle */ > + rect.left = 0; > + rect.right = GetSystemMetrics(SM_CXSCREEN); > + rect.top = 0; > + rect.bottom = GetSystemMetrics(SM_CYSCREEN); > + ClipCursor(&rect); > + Please don't add more init code that requires the graphics driver, I've been trying hard to get rid of these. I think it would be a lot cleaner to simply store a 'no clip cursor' state that would return the full resolution, then you could simply do a ClipCursor(NULL) on resolution changes. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Make LdrAccessResource Call an Internal Function to Satisfy Shrinker
by Dmitry Timoshkov 01 Nov '05

01 Nov '05

"Robert Shearman" <rob(a)codeweavers.com> wrote: > -/********************************************************************** > - * LdrAccessResource (NTDLL.@) > - */ > -NTSTATUS WINAPI LdrAccessResource( HMODULE hmod, const IMAGE_RESOURCE_DATA_ENTRY *entry, > - void **ptr, ULONG *size ) > +/* don't penalize other platforms stuff needed on i386 for compatibility */ > +#ifdef __i386__ > +NTSTATUS WINAPI access_resource( HMODULE hmod, const IMAGE_RESOURCE_DATA_ENTRY *entry, > + void **ptr, ULONG *size ) > +#else > +static inline NTSTATUS access_resource( HMODULE hmod, const IMAGE_RESOURCE_DATA_ENTRY *entry, > + void **ptr, ULONG *size ) > +#endif > { > NTSTATUS status; > > @@ -355,6 +358,30 @@ NTSTATUS WINAPI LdrAccessResource( HMODU > return status; > } > > +/********************************************************************** > + * LdrAccessResource (NTDLL.@) > + */ > +#ifdef __i386__ > +/* Shrinker depends on the "call access_resource" instruction being there */ > +__ASM_GLOBAL_FUNC( LdrAccessResource, > + "pushl %ebp\n" > + "movl %esp, %ebp\n" > + "pushl 24(%ebp)\n" > + "pushl 20(%ebp)\n" > + "pushl 16(%ebp)\n" > + "pushl 12(%ebp)\n" > + "pushl 8(%ebp)\n" > + "call access_resource\n" > + "leave\n" > + "ret\n" > +); > +#else > +NTSTATUS WINAPI LdrAccessResource( HMODULE hmod, const IMAGE_RESOURCE_DATA_ENTRY *entry, > + void **ptr, ULONG *size ) > +{ > + return access_resource( hmod, entry, ptr, size ); > +} > +#endif Shouldn't be enough for the __i386__ case just omitting 'inline' in access_resource definition? -- Dmitry.

2 1

Queries about some 'usability' points
by Lionel Ulmer 01 Nov '05

01 Nov '05

Hi all, There are just two (unrelated) points that I would like to discuss: = the possibility to add a 'wine' launcher. Basically what happens is that some (maybe only one :-) ) application takes as an assumption that it is started via 'double clicking' on the .EXE file or via the installed link. From what I know, both these actions will start the game from its .EXE directory and with the full qualified path as the exe name. So the application crashes if you start it with 'wine foo.exe', you need to type 'wine D:\\Foo\\foo.exe' to get it running. One could then imagine having either 'wine' be a launcher that qualifies the name, changes to the good directory and just start the 'real' wine or do the reverse: publicize to new users that they should use 'winelaunch' to start applications and keep 'wine' how it is now. = in the current Wine tree, if Wine crashes, some persistant X settings are changed (for example desktop resolution for people using XRandR)... And as most people do not know the 'xrandr' command line tool, they tend to kill X to restore their resolution (which tends to annoy them :-) ). In the same vein, I would like to disable mouse acceleration when DInput mode is entered but actually fear to do so for the above-mentionned reasons (I fear gettint these kind of lines in the IRC channels: 'Wine is crap, when it exits, I need to restart X to get my mouse acceleration back'). Well, there is 'xset' but most 'normal' users have no idea that it even exists... For that one, the most robust way would be at the X level (basically having 'connection-linked' configurations - i.e. the settings has changed up until the point in time that the client quits) but if we do not want to change X, the most robust way would be to do it at the wineserver level (I often get Wine crashing, it's more rare to get the server to crash). Of course, injecting X code in the server is maybe not to AJ's liking :-) So the other solution would be to be able to hook somehow some 'clean-up' functions from DLLs to the Wine process that could be called when Wine exits (whether normally or when crashing). Of course, people 'kill-9'ing their Wine would get nothing but I do not think it's really a problem. Lionel (in rant mode :-) ) -- Lionel Ulmer - http://www.bbrox.org/

7 25

Unix Path APIs implementation available
by Troy Rollo 01 Nov '05

01 Nov '05

An implementation of UNIX path APIs is available from: svn://troy.wine-branches.troy.rollo.name/troy/branches/unix-path-apis This is an SVK branch, so if you use SVK you will be able to merge it into your own branch. The implementation is also merged into the following trunks: svn://troy.wine-branches.troy.rollo.name/troy/trunk svn://wine-branch.corvu.com/corvu/trunk Not all APIs are implemented, rather a mechanism has been provided for specifying the interface of an entry point that is used by a tool that generates the UNIX path name entry points (it can also generate the 'A' versions of non-UNIX path name entry points). I will put some documentation on the Wiki.

1 0

Lockbox IPC implementation available - may be useful for wineserver "kernel" handles
by Troy Rollo 01 Nov '05

01 Nov '05

A couple of years back I described an IPC mechanism called "Lock boxes" that might be useful for creating a faster wineserver. An implementation of this for Linux is now available: <http://lockboxes.berlios.de/>

1 0