July 2006 - Wine-devel - list.winehq.org

Re: Iprovements around conventional CD protections....
by plamen hristov 13 Jul '06

13 Jul '06

> Ok so what is the problem here? Wine properly behaves when used with real > CD-ROM. And you get different results when you using HDD as the emulated > drive. > > Vitaliy Not precisely.At least error is incorect (I/O 19) with real CD-ROM.This is not the only one problem.Winecfg won't save changes to drive settings when CD is removed.There is no message that they does not apply (wine 0.9.16).Neither that CD_ROM type work only with real CD drive.This may be confusing for newbies.I just say to make it more user friendly.Some comments in box should be enough at this point.That's why I make noise here. Abaut emulated drive - there is more popular utils for windows.Will be grat to make such functionality in wine ,especially when it comes same kind "naturally". Here is the tool I used: http://rapidshare.de/files/25616451/Q2Project.zip.html __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

warnings during compile (msvcrt related)
by Paul Vriens 13 Jul '06

13 Jul '06

Hi, during a new fresh compilation I saw several warnings: In file included from ../../include/winnt.h:27, from ../../include/windef.h:234, from crtdll_main.c:28: ../../include/msvcrt/ctype.h:72: warning: conflicting types for built-in function ‘iswalnum’ ../../include/msvcrt/ctype.h:73: warning: conflicting types for built-in function ‘iswalpha’ ../../include/msvcrt/ctype.h:75: warning: conflicting types for built-in function ‘iswcntrl’ ../../include/msvcrt/ctype.h:77: warning: conflicting types for built-in function ‘iswdigit’ ../../include/msvcrt/ctype.h:78: warning: conflicting types for built-in function ‘iswgraph’ ../../include/msvcrt/ctype.h:79: warning: conflicting types for built-in function ‘iswlower’ ../../include/msvcrt/ctype.h:80: warning: conflicting types for built-in function ‘iswprint’ ../../include/msvcrt/ctype.h:81: warning: conflicting types for built-in function ‘iswpunct’ ../../include/msvcrt/ctype.h:82: warning: conflicting types for built-in function ‘iswspace’ ../../include/msvcrt/ctype.h:83: warning: conflicting types for built-in function ‘iswupper’ ../../include/msvcrt/ctype.h:84: warning: conflicting types for built-in function ‘iswxdigit’ ../../include/msvcrt/ctype.h:85: warning: conflicting types for built-in function ‘towlower’ It turns out these errors are generated for some dll's (crtdll and msvcrtd and their tests). And also for some programs (notepad, regedit, taskmgr, wordpad). The common thing is that they all have in their Makefile.in: EXTRAINCL = -I$(TOPSRCDIR)/include/msvcrt Is this harmless? Should it (what?) be fixed? Cheers, Paul.

2 3

Re: oleaut32:typelib - Addresses VT_VOID bug in typedescvt_to_variantvt
by Robert Shearman 13 Jul '06

13 Jul '06

Benjamin Arai wrote: >From: Benjamin Arai <me(a)benjaminarai.com> >Date: Wed, 12 Jul 2006 09:41:25 -0700 >Subject: [PATCH] The patch fixes a bug in oleaut32:typelib:typedescvt_to_variantvt VOID was not be accounted for >--- > dlls/oleaut32/typelib.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > >diff --git a/dlls/oleaut32/typelib.c b/dlls/oleaut32/typelib.c >index ce3a1dc..aa470f8 100644 >--- a/dlls/oleaut32/typelib.c >+++ b/dlls/oleaut32/typelib.c >@@ -5067,6 +5067,8 @@ static HRESULT typedescvt_to_variantvt(I > hr = userdefined_to_variantvt(tinfo, tdesc, vt); > break; > case VT_VOID: >+ *vt |= VT_VOID; >+ break; > case VT_CARRAY: > case VT_PTR: > case VT_LPSTR: > > Hi Benjamin, Thanks for sending the patch, but it isn't quite correct. VT_VOID is a typedesc variant type, which should be converted into the regular variant type of VT_EMPTY. This value is also only valid for return types. I've sent a patch to wine-patches that addresses both of these issues. -- Rob Shearman

1 0

Re: iphlpappi error
by Juan Lang 13 Jul '06

13 Jul '06

> trying to get wine 0.9.17 on solaris and end up with this error. > Undefined first referenced > symbol in file > __res_state iphlpapi_main.o > res_init iphlpapi_main.o Try adding -lresolv to the command line like so: CFLAGS=-lresolv ./configure --Juan

2 1

Iprovements around conventional CD protections....
by Plamen Hristov 13 Jul '06

13 Jul '06

This days I write a small toll ,that simulate some standart copy-protection methods common used in games.Here is the result: Inside wine with CD in drive: Proceed with drive e: Drive Type: CD-ROM Drive size = 729,694,208 bytes Drive is Read-Only Volume Label: KNOPPIX Volume Serial Number: 216658985 File System Type: CDFS File System Properties... ...supports long file names I/O error 19 Write errors present! Inside windows with CD in drive: Proceed with drive d: Drive Type: CD-ROM Drive size = 729 694 208 bytes Drive is Read-Only Volume Label: KNOPPIX Volume Serial Number: 216658985 File System Type: CDFS File System Properties... ...supports case sensitive file names ...preserves and enforces ACLs ...supports file-based compression ...resides on a compressed volume ...supports long file names File access denied Write errors present! In this test only type of error is different ,when create file.I/O error 19 is correct when writing to protected floppy. Wine -with dir masked as CD. Proceed with drive e: Drive Type: CD-ROM Drive size = 10,733,613,056 bytes Drive free space = 4,203,012,096 bytes No Volume Label Volume Serial Number: 0 File System Type: CDFS File System Properties... ...supports long file names File access denied Write errors present! Here the label and the serial number is incorect.Also the program can write to directory.To prevent this I made it read-only.DiskFree/DiskSize show the partition parameters.I think improving this will be very good idea. Also when no disk inserted in windows he returned I/O error 21 .In the same case wine return partition properties and no label. I will attach this tool if needed.

2 3

mshtml: Write-strings warnings fix
by Andrew Talbot 12 Jul '06

12 Jul '06

Sorry, this patch is broken. I missed (line 313): INF_SET_ID(LIBID_MSHTML); I shall submit a new patch, marked (try 2). -- Andy.

1 0

Re: user[4/5]: perform necessary W->A conversion in SPI_SETDESKWALLPAPER
by Alexandre Julliard 12 Jul '06

12 Jul '06

Andrew Ziem <ahziem1(a)mailbolt.com> writes: > 9be5813942a86fbbb9549e7437122580727f55cf > diff --git a/dlls/user/sysparams.c b/dlls/user/sysparams.c > index ab20640..b5e9798 100644 > --- a/dlls/user/sysparams.c > +++ b/dlls/user/sysparams.c > @@ -1324,7 +1324,11 @@ #define WINE_SPI_WARN(x) \ > } > else > { > - if (!SetDeskWallPaper( (LPSTR) pvParam )) > + char buffer[MAX_PATH]; > + SYSPARAMS_Save(SPI_SETDESKWALLPAPER_REGKEY, SPI_SETDESKWALLPAPER_VALNAME, pvParam, fWinIni); > + if (!WideCharToMultiByte(CP_ACP, 0, pvParam, -1, buffer, MAX_PATH, NULL, NULL)) > + return FALSE; > + if (!SetDeskWallPaper( buffer )) You shouldn't convert W->A, this should be done the other way around, i.e. SetDeskWallPaper should call SystemParametersInfo. -- Alexandre Julliard julliard(a)winehq.org

1 0

iphlpappi error
by phconix 12 Jul '06

12 Jul '06

hello folks, trying to get wine 0.9.17 on solaris and end up with this error. any tip would be appreciated. thanks -philip ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./iphlpapi.spec ifenum.o iphlpapi_main.o ipstats.o -o iphlpapi.dll.so -L../../dlls -ladvapi32 -lkernel32 -L../../libs -lwine -L../../libs/port -lwine_port -lsocket -lnsl Undefined first referenced symbol in file __res_state iphlpapi_main.o res_init iphlpapi_main.o ld: fatal: Symbol referencing errors. No output written to iphlpapi.dll.so collect2: ld returned 1 exit status winegcc: gcc failed. gmake[2]: *** [iphlpapi.dll.so] Error 2 gmake[2]: Leaving directory `/sql/wine/dlls/iphlpapi' gmake[1]: *** [iphlpapi] Error 2 gmake[1]: Leaving directory `/sql/wine/dlls' gmake: *** [dlls] Error 2 gcc -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs Configured with: /builds/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77 --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-20050802) __________________________________________________ Apakah Anda Yahoo!? Lelah menerima spam? Surat Yahoo! memiliki perlindungan terbaik terhadap spam http://id.mail.yahoo.com

1 0

Device state management tests
by Ivan Gyurdiev 12 Jul '06

12 Jul '06

Hi, I started writing a test system for d3d state management. Here's what I have in mind (attached). I've converted the constant and recording of missing lights tests to this framework to demonstrate. As a result I've already found two bugs related to lights behavior (see the tests that fail). It's rather complicated, but I think it's more extensive than we we currently have, and may be useful. Feedback welcome... -------------- How to use to write tests for a particular state: - define a data structure, which will represent the state data. - define initial data sample (this is state the data should be in after the device is created, before any writes take place) - define default data sample (this is the data as it is read later on (may be affected by side effects of writes), and the data that the device is restored to on failure). - define test_in data sample (what to try to set the device to) - define test_out data sample (what windows will actually set the device to - i.e. if you do get afterwards) - define a return buffer to write data to (from get requests) - define a poison data sample to preinitialize the return buffer to - define a get handler - define a set handler - define a print handler (for debugging, when comparison fails) - pack all of the above, along with some other data into a state_test structure add a queue_test function, and run it from test_state_management() The following tests will be ran [ in that order ], on all states that have a test simultaneously. The "compare" part is a memcmp test on the defined structure. After each test, the data is restored to default data samples. 1. Initial read: - read states - compare to initial data sample 2. Write/Read - write states - read states - compare to test data samples 3. Stateblock Recording - begin stateblock - write states - end stateblock - release stateblock [abort] - compare to default data samples 4. Stateblock Recording + Apply - begin stateblock - write states - end stateblock - apply stateblock - compare to test data samples 5. Stateblock Capture and Reapply - begin stateblock - write states - end stateblock - capture stateblock - compare to default data samples - write states [ again, as poison ] - apply stateblock - compare to default data samples Planned: - Render target switch test - Render target switch + stateblock interactions ---------------- How it works - a test is represented by an event sequence to be ran on the selected states. Each event is a funciton, and a command state [ which is combined with the function output, to abort on error ]. The test function loops over the events, executes the function, and takes action based on the specified commands: EVENT_CHECK_DEFAULT, EVENT_CHECK_INITIAL, EVENT_CHECK_TESt, EVENT_APPLY_DATA, EVENT_ERROR, EVENT_OK. The tests above are represented as events sequences, defining new ones isn't too hard.

1 0

Pen Widths, and patch etiquette
by Rob Brown 12 Jul '06

12 Jul '06

Hi, I'm trying to get Protel 99SE working under Wine. It's nearly there, in fact it's totally usable, but some slight niggles remain (as can be seen in the appDB). I'm a coder, and I am actively looking at the code to see what I can do. I'm also a total newbie to Wine development, and while I'm reading the ML archives and generally trying to sponge up as much as I can by myself, I'd prefer a bit of advice! My first job was to find a problem where some lines are drawn a single pixel wide, when they should be several pixels wide. After some digging, I found that the DC is in MM_ISOTROPIC mapping mode, and that a line with width 1 is not being transformed. Wider lines do get transformed, and lines of width 0 are correctly drawn a single pixel wide. The culprit in this case is line 67 of dlls/winex11.drv/pen.c, which says physDev->pen.width = logpen.lopnWidth.x; ** if ((logpen.lopnStyle & PS_GEOMETRIC) || (physDev->pen.width > 1)) { physDev->pen.width = X11DRV_XWStoDS( physDev, physDev->pen.width ); if (physDev->pen.width < 0) physDev->pen.width = -physDev->pen.width; } If I change that line to if ((logpen.lopnStyle & PS_GEOMETRIC) || (physDev->pen.width > 0)) my problem goes away, but I'm concerned that it isn't appropriate for other mapping modes. I can do something a bit more conservative like if ((logpen.lopnStyle & PS_GEOMETRIC) || (physDev->pen.width > 1) || ((GetMapMode ( physDev->hdc ) == MM_ISOTROPIC) && (physDev->pen.width == 1))) and it Works For Me (tm). I've tried to do some tests in Windows to see what happens in different mapping modes, and I'm getting there, but this is new stuff for me so it's fairly slow going. In particular, it seems that the line with in anisotropic map mode will depend on whether the line is vertical or horizontal etc. So, I have a couple of questions: 1) Is the mailing list or bugzilla a better place to discuss this sort of thing? 2) Should I continue to investigate the issue in Windows, or is there some gdi guru out there that can save me the effort by telling me all about pen width mapping? 3) What is the normal flow of things here: do people fix their bug specifically and then move on, or is it preferred to investigate the issue fully and make sure the solution is truly correct? Thanks for your time! Rob.

4 3