December 2007 - Wine-Devel - list.winehq.org

Re: kernel32: Add an ability to execute 32-bit applications from 16-bit ones using winoldap.dll
by Andrey Turkin Dec. 26, 2007

Dec. 26, 2007

Dmitry Timoshkov wrote: > Hello, > > this patch should fix the problem reported in the bug 3620. > > winoldap.mod in Windows is a 16-bit .exe which uses its command line to load > a 32-bit module and pass the parameters to it. Since winebuild doesn't allow > to create a 16-bit builtin exe, I decided to create a 16-bit builtin dll > instead. That adds some complexity due to need to create another thread to > launch a 32-bit application from, and wait until it finishes. > The application mentioned in the bug change current directory to output dir and then uses WINEXEC with relative filename to start child application. Thread created by winoldap uses another current directory because of something, so CreateProcess fails with your patch. <snip> > + if (CreateProcessA( NULL, cmdline, NULL, NULL, FALSE, > + 0, NULL, NULL, &startup, &info )) > + { > + HINSTANCE16 hwinoldap; > + > + /* Give 30 seconds to the app to come up */ > + wait_input_idle( info.hProcess, 30000 ); > + > + args->ret = TRUE; > + SetEvent(args->event); > + > + WaitForSingleObject( info.hProcess, INFINITE ); > + > + CloseHandle( info.hThread ); > + CloseHandle( info.hProcess ); > + > + /* decrement WINOLDAP usage count to signal that we have finished */ > + hwinoldap = GetModuleHandle16( "winoldap" ); > + FreeLibrary16( hwinoldap ); > + } > Usage count should be decremented regardless of CreateProcess return value. > + > + RestoreThunkLock( count ); > + HeapFree( GetProcessHeap(), 0, cmdline ); > + > + if (!args->ret); > + SetEvent( args->event ); > Typo.

2 1

Re: WineX11.drv: Add an X11 window for the client area [attempt3]
by Alexandre Julliard Dec. 25, 2007

Dec. 25, 2007

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > + if (data->client_window) > + { > + int w = data->client_rect.right - data->client_rect.left; > + int h = data->client_rect.bottom - data->client_rect.top; > + > + TRACE("Updating client window 0x%lx to %dx%x,%dx%d\n", data->client_window, > + data->client_rect.left, data->client_rect.top, w, h); > + > + if(w>0 && h>0) > + { > + wine_tsx11_lock(); > + XMoveResizeWindow(display, data->client_window, data->client_rect.left, > + data->client_rect.top, w, h); > + wine_tsx11_unlock(); You should do that only when the size has actually changed. > +static Window create_client_window( Display *display, struct x11drv_win_data *data) > +{ > + XSetWindowAttributes attr; > + > + attr.event_mask = ExposureMask; > + attr.bit_gravity = NorthWestGravity; > + attr.backing_store = NotUseful; Using NorthWestGravity is good but you still need to fix the valid rects calculation accordingly. > +static void destroy_client_window( Display *display, struct x11drv_win_data *data ) > +{ > + if (!data->client_window) return; > + > + wine_tsx11_lock(); > + > + XDeleteContext( display, data->client_window, winContext ); > + XDestroyWindow( display, data->client_window ); > + data->client_window = 0; > + XFlush(display); > + > + wine_tsx11_unlock(); The XFlush shouldn't be needed. > @@ -1569,7 +1648,19 @@ void X11DRV_SetParent( HWND hwnd, HWND parent, HWND old_parent ) > if (old_parent == GetDesktopWindow()) > { > /* destroy the old X windows */ > - destroy_whole_window( display, data ); > + > + /* Don't destroy the X11 window twice in order to prevent a BadWindow error, if the client window is the whole window */ > + if(data->whole_window == data->client_window) > + { > + destroy_whole_window( display, data ); > + data->client_window = 0; > + RemovePropA( data->hwnd, client_window_prop ); > + } The test is useless, if you are changing the parent of the desktop window something is very wrong... -- Alexandre Julliard julliard(a)winehq.org

2 2

Anyone know how to produce a win16 pkzip self-extractor?
by Dan Kegel Dec. 25, 2007

Dec. 25, 2007

To look into http://bugs.winehq.org/show_bug.cgi?id=3620 I wanted to create a 16 bit self-extracting archive. So I downloaded ftp://ftp.pkware.com/pk263w16.exe and followed the instructions in Help for creating a windows self-extractor. Sadly, 'file' on the resulting .exe says it's just a zip file. The help file says you can convert a .zip to a .exe using File / Convert, but that crashes with Unhandled exception: page fault on read access to 0xffffffff in 16-bit code (12e7:be9a). deep inside pkzip. So I tried the 32 bit version, which according to http://www.ecn.wfu.edu/~cottrell/pkzip.html#sfx can do it cross-platform. But when I tried http://www.filegate.net/pkware/pkwin32/pk250c32.exe with wine PKZIP25.EXE -add -sfx=win16 test *.TXT it said PKZIP: (E5) Unknown or illegal sub-option - sfx=win16 which, I think, means you have to be using a registered copy to do cross-platform self-extractors. I also tried the DOS version, and that just hung (grumble). Anyone figured out a way to do this yet? I filed a bug for a console problem related to pkzip, http://bugs.winehq.org/show_bug.cgi?id=10884 but not the crash yet. Perhaps the failure to create a real self-extractor is another bug, I haven't tried on windows xp yet. - Dan

5 5

Which is more important to Linux users, itunes or photoshop?
by Dan Kegel Dec. 24, 2007

Dec. 24, 2007

Not a real question, but I thought this graph was interesting: http://www.google.com/trends?q=dreamweaver+linux%2C+%22world+of+warcraft%22… It seems iTunes on Linux is twice as popular a query as Photoshop on Linux. No idea what that really means, but it does make me want to get our iTunes support shipshape... Then again, this graph shows mplayer beating out itunes (presumably because it works): http://www.google.com/trends?q=dreamweaver+linux%2C+mplayer+linux%2C++itune… OK, too much fooling around with graphs. Back to watching Underdog with my four-year-old...

8 8

Re: wined3d: add zero/near zero vertex rhw special case
by H. Verbeet Dec. 24, 2007

Dec. 24, 2007

On 25/12/2007, Alexander Dorofeyev <alexd4(a)inbox.lv> wrote: > > + if ((pos[3] < 1e-8) && (pos[3] > -1e-8)) You should probably use eps and -eps there, like the rest of the code does. Also, please write a test case to prevent this from regressing in the future.

1 0

Re: [wintab32 3/7] Add constants for cursor types and use them.
by Alexandre Julliard Dec. 24, 2007

Dec. 24, 2007

Jeremy White <jwhite(a)winehq.org> writes: > --- a/include/wintab.h > +++ b/include/wintab.h > @@ -525,6 +525,23 @@ typedef struct tagROTATION { /* 1.1 */ > #endif > > /*********************************************************************** > + * WACOM WINTAB EXTENSIONS TO SUPPORT CSR_TYPE > + * In Wintab 1.2, a CSR_TYPE feature was added. This adds the > + * ability to return a type of cursor on a tablet. > + * Unfortunately, we cannot get the cursor type directly from X, > + * and it is not specified directly anywhere. So we virtualize > + * the type here. (This is unfortunate, the kernel module has > + * the exact type, but we have no way of getting that module to > + * pass us that type). > + */ > + > +#define CSR_TYPE_PEN 0x822 > +#define CSR_TYPE_ERASER 0x82a > +#define CSR_TYPE_MOUSE_2D 0x007 > +#define CSR_TYPE_MOUSE_4D 0x094 This doesn't seem to belong in wintab.h. -- Alexandre Julliard julliard(a)winehq.org

1 0

The status of the wintab dll
by Robert North Dec. 24, 2007

Dec. 24, 2007

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think after the 10 or more patches to the Wintab dll that I submitted last month, I should say something about it's status... And of course thank Alexandre for applying those patches. P.S. I won't be available from the 15th for about a week or so. So, if you have any questions, I'm afraid you might have to be patient. Hope this is of interest to someone -Rob. ******Applications: Current status*********** ***In Painter 5 *Cursor pressure works. (Therefore is usable by most) *Cursor orientation is a little odd: The orientation maths needs to be re-done. *No eraser. Haven't yet cracked what enables the eraser. *Doesn't work in desktop mode: Need to map to desktop coordinates. *Repeats windows bugs where cursor looses pressure/orientation info almost bug for bug (Is this a feature? ;-) *Cannot detect pressure/orientation int the "Brush Tracking" window: The tablet context is attached to the main window, so no events get to the popup, even if they overlap. This is not how windows wintab functions. ***In Photoshop 6. *Can only get tablet data in desktop mode: This is because the tablet context is attached to the desktop. Which generates/receives no wine events outside desktop mode. * Eraser and pen pressure working. *But* to get them working, you must have 3 XInput devices listed in your XF86Config file, They need to be the last entries in the "ServerLayout" section and the following order: eraser, tablet mouse. This is a far from ideal way of specifying the devices Wintab should use :-/ I'll document this if someone can point me to a good place to put the docs. *******To Do************* 1. Look at X11 errors. There appear to be some errors that deny some users the ability to access Wintab enabled apps. (I think I know how to fix this) 2. Improve orientation data. Orientation comes in as X-Y coords (Implicit Z), and has to leave as spherical coords. This calculation needs to be re-done. 3. When tablet context is on top, let it read XInput events from all the app's top-level windows. (This simulates the fact that the context is usually designed to cover the whole screen) 4. When tablet context is attached to desktop, read XInput events from all the app's top-level windows. 5. Tests ~ --My current philosophy on tests is... ~ Use Photoshop & Painter, any formal tests ~ can be written if anyone else gets involved in patching Wintab, to avoid regressions, and conflict. **********Long term to do (Anyone interested?):********* There's a lot of work that could be done here, but what gets done and who does it probably depends upon whether anyone finds an app that needs these features. I'd love to implement these, but realistically, I don't foresee doing this unless someone hires me to do so ;) 1. Improve configuration of wintab. Wintab could probably do with some information entered into the config file, to avoid the user having to hack their Xfree86cfg file. 2. Handle Z-Order of context properly. This entails *sharing Z-Order between apps. *Working out exactly what role windows have in determining tablet context z-orders. *Allow tablet contexts that don't cover the whole screen/tablet. *Handle inter-application clipping of tablet contexts *Allow all application's windows to receive tablet events when tablet context is on top 3. Implement non-system tablet contexts (Where system cursor not moved by pen or mouse) 4. Unicodify 5. Implement various wintab extensions. 6. Implement wintab manager functions. 7. Tests. *********Unknowns********* 1. How are wintab contexts are raised lowered? Contexts have their own z-order independent of windows, and their own viewport concept, based upon the tablet's coordinate system, not that of the OS. It appears that entering, or clicking on the window the tablet context is attached to will raise/lower the context. But I haven't done much testing on this. In particular, what happens if more than one app request their tablet context is attached to the desktop? 2. How Painter detects the eraser. Have 3 possibilities i. Windows can detect an eraser, and sends specific messages. (I'm sure I've seen this, but can't work out where!) ii. Only works if tablet and cursors are named correctly. (Probably linked to wacom tablets only). iii. I've missed something 3. Requirements of other applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCC8zI2vfwxdLxwWYRAsisAJ4q2gAYTgRc6f9wDI+Ruv943eDxOQCfcl3s /ZKMUGwQOuw/SIIbOkIUbd0= =R4M7 -----END PGP SIGNATURE-----

2 1

Re: [wintab32 1/7] Store and use the physical device id to match device to cursor.
by Zachary Goldberg Dec. 24, 2007

Dec. 24, 2007

On Dec 23, 2007 11:55 AM, Jeremy White <jwhite(a)winehq.org> wrote: > ...snip.. > +static int cursor_from_device(DWORD deviceid, LPWTI_CURSORS_INFO *cursorp) > +{ > + int i; > + for (i = 0; i < gNumCursors; i++) > + if (gSysCursor[i].PHYSID == deviceid) > + { > + *cursorp = &gSysCursor[i]; > + return i; > + } > + > + ERR("Could not map device id %d to a cursor\n", (int) deviceid); > + return -1; > } > > ...snip.. Perhaps a silly and/or wrong observation but, is this in an effort to support multiple cursors?

2 1

Re: ole32: Fix a failed call to DllGetClassObject while retrievingclass object interface pointer.
by Rolf Kalbermatter Dec. 23, 2007

Dec. 23, 2007

James Hawkins [truiken(a)gmail.com] wrote: >Disassembling of any kind is prohibited. You don't have to convert the disassembly >to source code first to disqualify. By that strict definition starting up any decent debugger is already disqualifying. Not sure we want to go quite there. I wouldn't really know how to do some of my programs without sometimes using a debugger, although that happens to usually break into my own code but in the case of an exception, also not. Rolf Kalbermatter

2 1

tools/wineshelllink: do not execute applications directly, use 'start' utility instead
by Kirill K. Smirnov Dec. 23, 2007

Dec. 23, 2007

>> -Exec=env WINEPREFIX="${WINEPREFIX:-$HOME/.wine}" wine "$path" $args >> +Exec=env WINEPREFIX="${WINEPREFIX:-$HOME/.wine}" wine start "$path" $args >This is not correct. If console needs to be created for those apps and there >isn't one, then Wine should do it when starting an app. This is correct. "wine start" is the right way to start complicated (which use AllocConsole/FreeConsole and HWND) console applications (bug #10827 and bug #10867). I do not understand how to detect lack of console even for applications called from desktop shortcut. Dumb IO console is always present AFAIK. I tried to following: Create simple console application. #include <stdio.h> int main(void) { FILE *f = fopen("ia.txt", "w"); int ret; ret = fprintf(stdout, "qqq\n"); fprintf(f, "%d\n", ret); fclose(f); return 0; } compiled it as windows console app and run it: 1) $ wine a.exe 2) $ wine start a.exe 3) create a desktop shortcut and click on it. 1'), 2'), 3') compiled the same app as a UNIX app and run it via desktop shortcut. In all cases results are the same: successful output to stdout (res=4). This makes me think that stdio handles are always present. I may be wrong, just let me know. -- Kirill

1 0