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

Re: Stubbed additional VGA registers

by Jeremiah Flerchinger

Marcus Meissner wrote: > On Fri, Dec 09, 2005 at 04:39:50AM -0500, Jeremiah Flerchinger wrote: > >>Subject: [PATCH] Stubbed additional VGA register functionality: >> >>Modified "dlls/winedos/vga.c" with additional comments on VGA registers. >>Added stubs for a large number of output registers and specific offsets. > > > Please do some indentation .... > > Ciao, Marcus > > >>--- >> >>dlls/winedos/vga.c | 418 >>+++++++++++++++++++++++++++++++++++++++++++++++----- >>1 files changed, 379 insertions(+), 39 deletions(-) >> The problem was Mozilla Thunderbird was forcing encoding to UTF and removing much of the original file's whitespace. I've since resubmitted the patch, but am having to send it as an attachment. I'll wait for further feedback from people to hear if this is acceptable.

Dec. 10, 2005

Re: LoadImage (4bpp) / CopyImage() crashing

by Uwe Bonnes

>>>>> "Cyril" == Cyril Margorin <comargo(a)gmail.com> writes: Cyril> 2005/12/10, Mike McCormack <mike(a)codeweavers.com>: >> > Unfortunately, problem is that GetBitmapBits function in wine is > >> incorrect, and may causes a buffer overflow, but the GetDIBits isn't. >> >> Great. Then we need to fix it, not try avoid it. Cyril> Yes, but I'm out of ideas how to fix it. The problem is that it Cyril> takes in to account only physical pixmap (as it was called in Cyril> x11drv/bitmap.c) but it should take pair physical pixmap/logical Cyril> bitmap, and make pixels conversion from one to another. If you look in the archives, you will see that I also stumbles about crashes in CopyImage. My patches (by far not as elaborated as yours) where also not applied. I also was out of ideas and hoped somebody else would pick up the problem... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 10, 2005

Re: GCC 4.0.1 / WINE bug?

by peter＠piments.com

Anyone working on getting wine to work on gcc-4.xx? On Wed, 23 Nov 2005 01:14:17 +0100, Evil <wine(a)eternaldusk.com> wrote: > wino(a)piments.com wrote: > >> Have you tried 4.0.2 ? This seems to be the version adopted by >> distros using gcc4. >> >> I am rebuilding Gentoo with 4.1-beta . When I get to wine I'll post if >> I get the bug. >> >> regards. > > > Mandriva 2006 ships with 4.0.1 and does not have an official package for > 4.0.2 as of yet. > > -Jesse > > > -- Using Opera e-mail on Gentoo Linux

Dec. 10, 2005

Re: Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to

by Eric Pouech

> We never "load" a driver more than once. Winecfg calls winmm OpenDriver > which will only ever load a single instance of the driver into memory. > Subsequent OpenDriver calls will reference the existing in memory > driver. Wine models the single instance device driver that supports > multiple physical devices. what you end up with is a situation where: - two calls to OpenDriver for the same driver will provide: + a separate HDRVR (one for each call) + the same driver ID at the driver level + an implementation at the driver level with a single data state shared across the two HDRVR instance - most of the drivers are not prepared for that. As a simple example: h1 = OpenDriver("a.drv", ...); h2 = OpenDriver("a.drv", ...); // h1 <> h2, but driver ids are the same // start a play back on one of media stream of a.drv with h1 CloseDriver(h2, 0, 0); // playback will stop, and all data of h1 have been cleared // by closing h2 ! >> Secondly, I do think it's a bad idea to reconstruct in winecfg most >> the driver management. It's not done correctly (the DRV_INIT, >> DRV_ENABLE and DRV_LOAD messages are not correctly passed). If it >> works today, it's by chance as the configure message is never handled >> (we just put out a message box), but it doesn't access the internal >> structures. To do it, we need the DRV_ messages sent. > > > It is true that winecfg is not calling each sub system driver (WaveIn, > WaveOut, ...) like windows but device probing is done at main driver > load in most drivers (and I am fixing the ones that don't) because > device configuration is dynamic rather than read from the registry so > opening the sub drivers individually to query static data is not a > problem. I have a version of the alsa driver that can change registry > entries from the configure dialog. yes, but it implies that all drivers configured by winecfg must be single instance drivers. >> Finally, I'm not sure that presenting all the drivers, and the ports >> available is really meaningful for most users. Some drivers return >> just potential entries (esound for example). Even with the caps, most >> users won't tell the difference between alsa and oss entries. > > > Jack and esound are fundamentally flawed because they create 10 virtual > sound cards that all reference a single physical device. This doesn't > take into account multiple devices. The proper way to implement this is > to allow multiple opens of the same device (just like windows). That > way two or more programs can open one card and other programs can open > another card and none of the programs are aware or even care about the > others. I have multiple sound cards and headsets in a single computer > for music and VoIP and I need a way for individual programs to work with > specific devices (just like in windows). we do agree here that jack & esound (like any interface with integrated audio mixer) should be multiple instance drivers and not single instance ones. [snip] > Hiding stuff in the registry without giving the user an easy > way (GUI rather than reading the source and using regedit) of > configuring the sound system is not good. that's not what I'm asking for. I request having even for winecfg driver loading/unloading to be handled through winmm, and not by winecfg itself, which forces you in lots of unneeded kludges. > The direction I am trying to take the winecfg it to allow specific > driver configuration through the windows DRV_CONFIGURE mechanism which > displays a driver specific dialog box for changing driver specific > registry entries. This is the only time there is potential contention > problems between programs but only if configuration is performed > immediately while the other programs are accessing the driver. that's not true see above A+ -- Eric Pouech

Dec. 10, 2005

Re: WIDL: Don't Output __RPC_FAR In Generated Code

by Robert Shearman

Hans Leidekker wrote: >On Friday 09 December 2005 20:21, Robert Shearman wrote: > >(note: I see no problem with this patch) > > print_server("*(("); > write_type(server, def->type, def, def->tname); >- fprintf(server, " __RPC_FAR *)_StubMsg.Buffer)++ = _RetVal;\n"); >+ fprintf(server, " *)_StubMsg.Buffer)++ = _RetVal;\n"); > >I remember sending a patch for the MIDL generated oleaut32/oaidl_p.c to >remove all these lvalue casts that had become illegal with the arrival >of gcc4 ("invalid lvalue in assignment"). To avoid these in widl the code >could read something like this: > > print_server("*("); > write_type(server, def->type, def, def->tname); > fprintf(server, " *)_StubMsg.Buffer = _RetVal;\n"); > fprintf(server, "_StubMsg.Buffer += sizeof("); > write_type(server, def->type, def, def->tname); > fprintf(server, ");\n"); > >I don't have my repository at hand now but I can send a patch this weekend. > I did plan to fix this in the future, but in reality the generated code isn't of much use yet, even if it were to compile correctly as it only accepts non-pointer basic types. Once the code becomes good enough for us to generate code for the svcctl or winreg interfaces then we will need touches like this. -- Rob Shearman

Dec. 10, 2005

Polish translations

by Biuro Fornet MK

Dear Sirs. I represent Polish company. We start currently a project - kind of computer helpdesk, where we advice (because of lot of reasons) moving to Linux to our customners. While they are in most cases very sceptic about this, your Wine makes a great help for us. Unfortunately, the English language is still the biggest barrier for Polish customers. Thats why we would like to contribute to Wine development and spreading a "good hope" :) in the way we can afford right now. I would like to propose: 1. full translation of your WWW page to Polish, and setting this "localisation" at our www host.server. 2. full translation - or help if anyone started, although i cant find any note on your site - of Wine software: GUI/API/DOCS/help docs into Polish. 3. Support for Polish users of Wine; if commercial - divided fifty/fifty with you - just to support this software. We can provide for translations work a group of 2 ppl, having both linguistic skills and Linux/IT knowledge, who can keep this project going on without the risk of sudden break or cooperation cancell. Unfortunately they cant do this project exclusively (they must do company jobs) but we will do our best to supply all we propose. Looking to hear from you - any time you can answer :) -- Yours sincerely, Marcin Kaskiewicz FORNET MK ul. Tuwima 16, 90-003 Łódź POLAND NIP: 726-226-70-21 REGON: 47 28 63 570 biuro(a)fornetmk.com

Dec. 10, 2005

Re: LoadImage (4bpp) / CopyImage() crashing

by Willie Sippel

Am Freitag, 25. November 2005 18:22 schrieb Cyril Margorin: > Hello, > > During research the crashing application I've found a problem that can > be easily reproduced by test. > (http://www.winehq.org/pipermail/wine-patches/2005-November/022384.html) > > By investigation of problem I've found that original DIB bit depth is > 4bpp, Physical pixmap bit depth is (equal to screen) 24bpp. > In x11drv/bitmap.c X11_GetBitmapBits takes in account just only bit > depth of physical pixmap, and copies it to provided buffer as-is. > I.e. it tries to fill buffer with size (e.g.) 48x48x4bpp with > 48x48x24bpp that causes buffer overrun and late falling in > SetBitmapBits function. > I just noticed that the Poser 6.0 demo also seems to crash at X11_GetBitmapBits, but your patch makes no difference. Don't know if it's supposed to... Anyway, in case you're interested, the Poser 6 crash, including a +x11drv trace and a link to the demo, is filed as bug 4034: http://bugs.winehq.org/show_bug.cgi?id=4034 > The current work-around to stop falling is > Index: dlls/x11drv/bitmap.c > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/bitmap.c,v > retrieving revision 1.18 > diff -u -r1.18 bitmap.c > --- dlls/x11drv/bitmap.c 26 Sep 2005 11:04:12 -0000 1.18 > +++ dlls/x11drv/bitmap.c 25 Nov 2005 09:29:12 -0000 > @@ -186,7 +186,19 @@ > /* copy XImage to 16 bit padded image buffer with real bitsperpixel */ > > startline = buffer; > - switch (physBitmap->pixmap_depth) > + > + > /********************************************************************** + > * CoMargo: the switching for physBitmap->pixmap_depth is not correct. + > * It should take both physBitmap->pixmap_depth and bitmap.bmBitsPixel + > * and convert from one bitdepth to another. > + * Otherwise we meet buffer overrun. > + */ > + if(physBitmap->pixmap_depth != bitmap.bmBitsPixel) > + { > + FIXME("Pixel conversion from %d bitdepth to %d bitdepth MUST be > done!\n",physBitmap->pixmap_depth,bitmap.bmBitsPixel); > + } > +/* switch (physBitmap->pixmap_depth) */ > + switch(bitmap.bmBitsPixel) > { > case 1: > for (h=0;h<height;h++) > =================================================================== > > -- > Cyril Margorin Ciao, Willie -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

Dec. 10, 2005

Re: new stubs for crypt32

by James Hawkins

On 12/9/05, Christoph von Wittich <Christoph(a)apiviewer.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > The following stubs should be added to crypt32.spec: > > @ stub CertVerifyCertificateChainPolicy > @ stub CertGetNameStringA > @ stub CertGetNameStringW > > > CertGetNameString is req. by eMule and CertVerifyCertificateChainPolicy > iby MS Genuine Check. > The apps that require these APIs would still crash if those lines were added to crypt32.spec. You would have to stub out the APIs in cert.c (the apps probably still wouldn't work if they're not implemented though). -- James Hawkins

Dec. 10, 2005

Re: LoadImage (4bpp) / CopyImage() crashing

by Cyril Margorin

2005/12/10, Mike McCormack <mike(a)codeweavers.com>: > > Unfortunately, problem is that GetBitmapBits function in wine is > > incorrect, and may causes a buffer overflow, but the GetDIBits isn't. > > Great. Then we need to fix it, not try avoid it. Yes, but I'm out of ideas how to fix it. The problem is that it takes in to account only physical pixmap (as it was called in x11drv/bitmap.c) but it should take pair physical pixmap/logical bitmap, and make pixels conversion from one to another. -- Cyril Margorin

Dec. 9, 2005

Re: LoadImage (4bpp) / CopyImage() crashing

by Cyril Margorin

the second email was send with patched created using such command: -- cvs diff -u dlls/user/cursoricon.c > user_cursoricon_copyimage.patch -- Is it correct? (I'm sorry, my cvs experience is not big enough). Also I added 'diff -u' line to my .cvsrc file. According to CreateDCW function - this block was looked up from same file. It uses static variable screen_dc.... But may be you are right, GetDC(0) should be used. 2005/12/10, Vitaliy Margolen <wine-devel(a)kievinfo.com>: > Friday, December 9, 2005, 3:12:23 PM, Cyril Margorin wrote: > > Hello, > > > Could anyone tell me, why function CopyImage uses > > GetBitmapBits/SetBitmapBits, while MSDN marks these function as > > absolete? > > Because what MSDN says doesn't really mean it's the same on Wine. But my > guess would be that it's been implemented that way and no one changed it. > > > I've tried to move from GetBitmapBits/SetBitmapBits to > > GetDIBits/SetDIBits. It seems to me that this way is correct, if keep > > in mind, that GetBitmapBits is wrong. > > > > In attachment you may find a patch for it. > > Please use unified format from the to of the tree. (looks like you beat > me to it). > > But your patch looks like 10x more then what was there before. > Also you are using CreateDCW which a really heavy function IMHO for what > you need. Why don't use GetDC(0)? > -- Cyril Margorin

Dec. 9, 2005