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

Re: wrc doesn't seem to accept -r option,even though it is automatically generated by make file
by Parzival Herzog 15 Nov '03

15 Nov '03

On November 10, 2003 15:34, Ivan Leo Murray-Smith wrote: > You can easily upgrade to the october build, a GUI (winesetuptk) can write > the config for you, see > www003.portalis.it/115/ I am sending you email, because your message did not appear on the mailing list, so I can't respond to it there. I hope this is OK with you. As I said in the original post, I am not a wine "developer" (too ignorant for that), I am a (potential) user of the wine library, and the wine-user list people seemed to think my question was for wine-devel. At this point I don't even know if I have a bug or some finger-trouble, and if I have a bug, it is with an old version, yet a newer version gives me big problems, so I dont't want to go to the bug report stage if all I am doing is making some stupid mistake. The link http://prdownloads.sourceforge.net/wine/wine-20031016-mdk9.1.i586.rpm?downl… is broken. The latest rpm there for Mandrake is dated 20030911. I believe that is the version I downloaded and which would crash on starting my programs, which as I said, is the reason I reverted back to the version that came with Mandrake 9.1. There is no Mandrake rpm at Sourceforge for wine-devel, so which wine-devel rpm should I use? Given that I can obtain a complete set of compatible rpms, do I need to un-install my present wine installation? What will happen to my .wine directory? Will the old config info be used, or will it confuse the new installation? I have my own "wine" directory, under which is my own assembly of a "windows" installation, which took some time to get right. Should I keep this? -- Parzival Herzog

2 1

looking for some help with DIB code from WINE
by Jonathan Wilson 15 Nov '03

15 Nov '03

I am working on ReactOS and would like to take the code in static void X11DRV_DIB_SetImageBits_RLE4( int lines, const BYTE *bits, DWORD width, DWORD dstwidth, int left, int *colors, XImage *bmpImage ) and static void X11DRV_DIB_SetImageBits_RLE8( int lines, const BYTE *bits, DWORD width, DWORD dstwidth, int left, int *colors, XImage *bmpImage ) And use it as a jumping-off point to add support for RLE butmaps into ReactOS. Looking at the parameters, I can see that: XImage *bmpImage is the image itself (basicly, I guess its the X11 equivelent of a HDC or a HBITMAP or something) int *colors is the color table and const BYTE *bits is the bits themselves. since ReactOS is only going to uncompress and store the bitmap bits, we dont need to worry about the color table or the XImage Anyhow, what I want to know is what the int lines, DWORD width, DWORD dstwidth, and int left parameters to these 2 functions mean.

1 0

Re: Wintab32 - Tablet support
by Robert Shearman 15 Nov '03

15 Nov '03

> Hi, > > This is more a question for the developers.... Should have posted to wine-devel then :) Doing so now. > A couple of months ago there was a patch from Aric Stewart that added > support for graphics tablets in wine. However I have not heard anything > about it since. Is anybody still working on this? > Graphics tablet > support is the only thing stopping us from using Photoshop under Linux > at the present time. Moving all our graphics artists off dual booting > windows machines would be extremely benificial! > > I tried the original patch but found it affected the > stability of wine... I noticed that in the original patch a lot of functions were called from DllMain that shouldn't be called from there. Did the backtrace include wintab32.DllMain? The initialisation should probably be moved to either each function with a line like "if (!initialised) Initialise();" Alexandre, how come this patch hasn't been included in Wine yet? Was it the problem stated here or something else? > Daire Rob

2 1

keyboard warnings
by Jérôme Bouat 14 Nov '03

14 Nov '03

Due to recent changes in dlls/x11drv/keyboard.c, I compiled wine with CVS from 2003/nov/14. Although I use a french keyboard, the layout has some problems. I already provided a patch which avoids the warnings but it was a dirty hack. Running Microsoft Word 97 shows those warnings: --- [j(a)laptop tmp]$ wine /var/wine/Program\ Files/Microsoft\ Office/Office/WINWORD.EXE Loading required GL library /usr/X11R6/lib/libGL.so.1.2 fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (French keyboard layout) for scancode mapping. Please define your layout in dlls/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. fixme:x11drv:X11DRV_GetDeviceCaps (0x730): CAPS1 is unimplemented, will return 0 fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:ole:CoRegisterMessageFilter stub err:clipboard:X11DRV_CLIPBOARD_UpdateCache Failed to cache clipboard data owned by another process. fixme:ole:CoRegisterMessageFilter stub [j(a)laptop tmp]$

3 2

Re: ntdll / kernel32: #36
by Dmitry Timoshkov 14 Nov '03

14 Nov '03

"Eric Pouech" <pouech-eric(a)wanadoo.fr> wrote: > +static void INT21_ConvertFindDataAtoW(WIN32_FIND_DATAA *dataA, > + const WIN32_FIND_DATAW *dataW) > +{ > + dataA->dwFileAttributes = dataW->dwFileAttributes; > + dataA->ftCreationTime = dataW->ftCreationTime; > + dataA->ftLastAccessTime = dataW->ftLastAccessTime; > + dataA->ftLastWriteTime = dataW->ftLastWriteTime; > + dataA->nFileSizeHigh = dataW->nFileSizeHigh; > + dataA->nFileSizeLow = dataW->nFileSizeLow; > + WideCharToMultiByte( CP_OEMCP, 0, dataW->cFileName, -1, > + dataA->cFileName, sizeof(dataA->cFileName), NULL, NULL ); > + WideCharToMultiByte( CP_OEMCP, 0, dataW->cAlternateFileName, -1, > + dataA->cAlternateFileName, sizeof(dataA->cAlternateFileName), NULL, NULL ); > +} This is just a nit picking, but the function name above should be changed to INT21_ConvertFindDataWtoA (and perhaps the arg sequence should be changed as well). Of course, that could be done later, after the patch is committed. -- Dmitry.

1 0

LinuxWorld Expo NY
by Jeremy White 14 Nov '03

14 Nov '03

Hi All, I somewhat impetuously requested a table for the Wine Project at the LinuxWorld New York expo, without really thinking if anyone could man the table. We'll have a CodeWeavers specific area in another part of the expo, so we won't really be able to provide a lot of help (and won't need any extra promotion). So, I was wondering if anyone wanted to go to New York and represent the Wine Project. If so, let me know privately. If I don't hear anything, I'll quietly tell IDG <small> nevermind </small>. Cheers, Jer

1 1

unsubscribe samjack
by Rand Batchelder 13 Nov '03

13 Nov '03

__________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree

2 1

old addition: winetests
by Ferenc Wagner 13 Nov '03

13 Nov '03

Hello, I am making slow progress with this thing. It grew sort of usable: can be cross compiled and run to produce sensible output (tested on XP only). Present questions: 1. How to integrate cross compilation into the Makefile? 2. It is possible to compile this as a Winelib application, but the spawn call must be modified to invoke Wine instead of the test itself. Gives better results for the comctl32 tests (DPA import et al.), but is it worth it? Do we need is_elf and friends? 3. How to derive/give the cleaning rules? 4. Did Jon Bright contribute his SMTP client in the end? We could as well use it... Or would it be better (more reliable) to POST it through HTTP? 5. The #include section at the top of main.c looks weird. (It is the minimum to compile without warnings.) Maybe mkdir() should be moved into port.h? 6. EXTRADEFS = -DWINELIB is probably the wrong way. 7. Is there a way to get this into CVS after all? Feri.

8 13

Re: int21 handling
by Jukka Heinonen 13 Nov '03

13 Nov '03

A few comments about this patch by Eric Pouech. Structure DosHeap must not be moved to winedos. There already exists per drive media ID byte which should be used and biosdate, while it may be needed by some programs, won't do any good in a separate 16-bit segment. Also, INT21_CreateHeap is unnecessary. IOCTL 0x0860 and CreateBPB should include FIXME comments because it does not check real drive types nor real drive geometry. The same is true with other IOCTLs that return fake values. INT21_NetworkFunc should return NETBIOS name. There is a separate Win32 API for returning proper names, don't use gethostname. INT21_GetDriveAllocInfo should pass drive as a parameter, rewriting registers makes code less readable. As far as I know, TRUENAME implementation is broken. Add big FIXME notes to that subfunction. Use INT21_MapDrive instead of manual conversion from zero=default into zero='A' convention, that is why it is there. Use wide characters and manual wide character conversions. DOS routines use OEM code page and not ANSI code page and Wine uses wide characters as default character set, anyway. Also, adding drive number to 'A' may work incorrectly with illegal drives and 8-bit character set but it works fine with wide character set. -- Jukka Heinonen <http://www.iki.fi/jhei/>

3 5

Tests too noisy. [Fwd: Your message to wine-tests-results awaits moderator approval]
by aewine 13 Nov '03

13 Nov '03

Ok, that's it. I think many of the conformance tests are way to noisy. Many of them spews out lots and lots of output EVEN when they actually pass. It clutters the log, making it harder to read - and now this; so big a test log it awaits moderation. :-) Should I submit patches making the conformance tests much more quiet when passing - would the patches be applied? (Or is there some rationale to the massive chattering from the tests?) regards, Jakob ------------------------------------------------------- Your mail to 'wine-tests-results' with the subject Wine regression test, OS=5.1 FAILURES TESTS=20031027 Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 145447 bytes but there's a limit of 128 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision.

2 1