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

Re: [PATCH 3/4] msi: automation: Generalize list implementation.

by Stefan Dösinger

Am Freitag 18 Mai 2007 23:17 schrieb Misha Koshelev: > On Fri, 2007-05-18 at 20:15 +0200, Alexandre Julliard wrote: > > Misha Koshelev <mk144210(a)bcm.edu> writes: > > > if (wFlags & DISPATCH_PROPERTYGET) { > > > V_VT(pVarResult) = VT_I4; > > > - V_I4(pVarResult) = data->iCount; > > > + V_I4(pVarResult) = data->ulCount; > > > > I committed this patch, but I can't resist pointing out that if you > > had simply named the field "count" instead of using the (idiotic) > > Hungarian notation, the code would be just as clear, and you wouldn't > > need to rename it everywhere when making it unsigned... > > So is the general recommendation for wine that we not use Hungarian > notation then? Alexandre usually calls it Hungarian Line Noise, I guess that means "no".

May 18, 2007

Re: [PATCH 3/4] msi: automation: Generalize list implementation.

by Misha Koshelev

On Fri, 2007-05-18 at 20:15 +0200, Alexandre Julliard wrote: > Misha Koshelev <mk144210(a)bcm.edu> writes: > > > if (wFlags & DISPATCH_PROPERTYGET) { > > V_VT(pVarResult) = VT_I4; > > - V_I4(pVarResult) = data->iCount; > > + V_I4(pVarResult) = data->ulCount; > > I committed this patch, but I can't resist pointing out that if you > had simply named the field "count" instead of using the (idiotic) > Hungarian notation, the code would be just as clear, and you wouldn't > need to rename it everywhere when making it unsigned... > So is the general recommendation for wine that we not use Hungarian notation then? Misha

May 18, 2007

RE: advapi32: Route all 4 EnumServicesStatus[Ex] calls to a single stubto avoid code duplication

by Rolf Kalbermatter

Paul Chitescu wrote: >Changelog: advapi32: Route all 4 EnumServicesStatus[Ex] calls to a single >stub to avoid code duplication > >Most of the actual enumeration is common code so it makes sense to implement it only once. This is a possible approach. I had intended to just make use of EnumServicesStatusExW from all other functions with some translation in them. Your approach avoids translations at the cost of making the common enumeration function quite a bit more complicated. I'm not sure which one I like more. Rolf Kalbermatter

May 18, 2007

ADVAPI32: service tests

by Rolf Kalbermatter

While working on some advapi32.service functions I found that having some tests for those APIs could be very useful. However nbot having added completely new tests so far there are a few issues I feel intimidated about. The actual task of adding a new test file service.c does seem fairly straightforward to me, considering I can just take some other test file and copy the framework from it, adding the new service.c to the Makefile.in. However there are a few issues I see. First almost any test won't make much sense without at least one service installed and activated. As it is now there seem to be no services installed by default in a clean Wine install. So I guess I would also need an extra executable somehow that implements a basic service that could for instance communicate through a pipe with the service test. It could be as simple as an executable that implements all the necessary communication with the service manager and offers some sort of pipe loopback as main service activity. But how am I going to add such an extra executable to the make logic of the advapi32 test? Also under real Windows installing a service will in many cases fail since that requires administrative privileges for the current process and I'm not sure we can and want to enforce something like that especially for the unattended wine test service if that is still working. I would really appreciate some help about adding an extra executable to the creation to the advapi32 make logic so that meaningful tests could be done on Wine. Or maybe someone knows of a service that is going to be added to a standard Wine installation soon? Rolf Kalbermatter

May 18, 2007

Re: [PATCH 3/4] msi: automation: Generalize list implementation.

by Alexandre Julliard

Misha Koshelev <mk144210(a)bcm.edu> writes: > if (wFlags & DISPATCH_PROPERTYGET) { > V_VT(pVarResult) = VT_I4; > - V_I4(pVarResult) = data->iCount; > + V_I4(pVarResult) = data->ulCount; I committed this patch, but I can't resist pointing out that if you had simply named the field "count" instead of using the (idiotic) Hungarian notation, the code would be just as clear, and you wouldn't need to rename it everywhere when making it unsigned... -- Alexandre Julliard julliard(a)winehq.org

May 18, 2007

Re: RegDeleteTree [5]

by Juan Lang

Hi Stefan, + if (ret) return ret; + + ret = RegDeleteTreeW(hSubKey, lpszName); + if (ret) return ret; you've followed James's advice, but now you leak hSubKey (when it isn't hKey) and lpszName (when it isn't szNameBuf.) A goto would be better. --Juan ____________________________________________________________________________________Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&…

May 18, 2007

Re: ntdll: Protect RtlAllocateHeap and RtlReAllocateHeap against integer overflows with large values of size.

by Robert Shearman

Chris Robinson wrote: > On Friday 18 May 2007 05:12:30 am you wrote: > >> An example that would break using your logic: >> 2 + (-1) >> > > SIZE_T (if it follows standard size_t) is unsigned, though. Adding a negative > wouldn't be possible. Yes, you're right. The second parameter should probably be SSIZE_T. -- Rob Shearman

May 18, 2007

Re: ntdll: Protect RtlAllocateHeap and RtlReAllocateHeap against integer overflows with large values of size.

by Chris Robinson

On Friday 18 May 2007 05:12:30 am you wrote: > An example that would break using your logic: > 2 + (-1) SIZE_T (if it follows standard size_t) is unsigned, though. Adding a negative wouldn't be possible.

May 18, 2007

Re: ntdll: Protect RtlAllocateHeap and RtlReAllocateHeap against integer overflows with large values of size.

by Robert Shearman

Chris Robinson wrote: > On Friday 18 May 2007 04:01:19 am Robert Shearman wrote: > >> + ULONGLONG llret = (ULONGLONG)a + b; >> + if ((sizeof(SIZE_T) < sizeof(ULONGLONG)) && (llret > 0xffffffff)) >> + return FALSE; >> > > WOuldn't this be more correct (as well as function when sizeof(SIZE_T) >= > sizeof(ULONGLONG)): > > SIZE_T res = a + b; > return (res >= a); > An example that would break using your logic: 2 + (-1) -- Rob Shearman

May 18, 2007

Re: ntdll: Protect RtlAllocateHeap and RtlReAllocateHeap against integer overflows with large values of size.

by Chris Robinson

On Friday 18 May 2007 04:01:19 am Robert Shearman wrote: > + ULONGLONG llret = (ULONGLONG)a + b; > + if ((sizeof(SIZE_T) < sizeof(ULONGLONG)) && (llret > 0xffffffff)) > + return FALSE; WOuldn't this be more correct (as well as function when sizeof(SIZE_T) >= sizeof(ULONGLONG)): SIZE_T res = a + b; return (res >= a);

May 18, 2007

Re: msxml3 [1/4]: Add initial implementations of IXMLElement and IXMLElementCollection

by Huw Davies

On Thu, May 17, 2007 at 04:40:06PM -0500, James Hawkins wrote: > > Changelog: > * Add initial implementations of IXMLElement and IXMLElementCollection. I can't help thinking that it would have been cleaner to implement the IXML stuff using the IXMLDOM interfaces rather than straight on top of libxml. That way we only get one set of interfaces that depend on libxml. It may not be possible, but I think it would be worth a look. Huw. -- Huw Davies huw(a)codeweavers.com

May 18, 2007

Re: wininet: Add support for SSPI authentication for HTTP.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > In this case, it is. The "Basic" string should be followed by some > additional data which is parsed later. Yes, but AFAICS it's still supposed to be a separate token, so you'd need to check for a token separator. I don't think "Basically" should be considered a match for Basic authentication. -- Alexandre Julliard julliard(a)winehq.org

May 18, 2007

Re: 3/4 setupapi: Correctly handle an empty filename in SetupGetSourceFileLocationA.

by Hans Leidekker

On Friday 18 May 2007 11:43:29 James Hawkins wrote: > > Correctly handle an empty filename in SetupGetSourceFileLocationA. > > Please add a test case. The BITS installer was enough of a test case for me here, but since you ask, I'll see what I can do. -Hans

May 18, 2007

Re: wininet: Add support for SSPI authentication for HTTP.

by Robert Shearman

Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > >> Hmm, it seems strncmpiW already does that for me so I'm a little confused: >> >>> int strncmpiW( const WCHAR *str1, const WCHAR *str2, int n ) >>> { >>> int ret = 0; >>> for ( ; n > 0; n--, str1++, str2++) >>> if ((ret = tolowerW(*str1) - tolowerW(*str2)) || !*str1) break; >>> return ret; >>> } >>> > > It does if the string is shorter, but not if it's longer. It's OK if > you want to check that the string is a strict subset, but that's not > usually what you want. In this case, it is. The "Basic" string should be followed by some additional data which is parsed later. -- Rob Shearman

May 18, 2007

Re: 3/4 setupapi: Correctly handle an empty filename in SetupGetSourceFileLocationA.

by James Hawkins

On 5/18/07, Hans Leidekker <hans(a)it.vu.nl> wrote: > > -Hans > > Changelog > Correctly handle an empty filename in SetupGetSourceFileLocationA. > Please add a test case. -- James Hawkins

May 18, 2007

Re: 2/4 setupapi: Don't return ERROR_WRONG_INF_STYLE when there is no version section.

by James Hawkins

On 5/18/07, Hans Leidekker <hans(a)it.vu.nl> wrote: > > -Hans > > Changelog > Don't return ERROR_WRONG_INF_STYLE when there is no version section. > This is a change that is begging for a test case. -- James Hawkins

May 18, 2007

Re: wininet: Add support for SSPI authentication for HTTP.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Hmm, it seems strncmpiW already does that for me so I'm a little confused: >> int strncmpiW( const WCHAR *str1, const WCHAR *str2, int n ) >> { >> int ret = 0; >> for ( ; n > 0; n--, str1++, str2++) >> if ((ret = tolowerW(*str1) - tolowerW(*str2)) || !*str1) break; >> return ret; >> } It does if the string is shorter, but not if it's longer. It's OK if you want to check that the string is a strict subset, but that's not usually what you want. -- Alexandre Julliard julliard(a)winehq.org

May 18, 2007

Re: hhctrl.ocx: Parse HTML entities in the table of contents.

by Robert Shearman

Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > >> + /* hexadecimal entity */ >> + while ((*p >= '0' && *p <= '9') || (*p >= 'a' && *p <= 'f') || >> + (*p >= 'A' && *p <= 'F') || (*p == ';')) >> + p++; >> > > You should exit the loop at the first ';'. Also you have to increment > p first. > > >> + while (isalpha(*p)) >> + p++; >> > > You can't use ASCII ctype functions on Unicode chars. > Thanks, I'll send an updated patch which should address these comments. >> + for (i = 0; i < sizeof(char_refs)/sizeof(char_refs[0]); i++) >> + if (p - start - 1 <= sizeof(char_refs[i].name)) >> + { >> + if (!strncmpW(char_refs[i].name, start + 1, p - start - 1)) >> + break; >> + } >> > > The sizeof check doesn't make much sense, especially inside the > loop. What you need is to check that you reached the end of the string > if the strncmpW succeeded. Again, I'm not sure what you mean here. I know (start + 1) -> p will not have any nul's in it, therefore strncmpW will return non-zero if char_refs[i].name has a nul in it before (p - start - 1) characters. I wrote a small test program to prove this: static const WCHAR str1[] = {'t','e','s','t',0}; static const WCHAR str2[] = {'t','e','s','t','s','t','r','i','n','g',0}; printf("strncmpW(str1, str2, sizeof(str2)/sizeof(str2[0])-1) = %d\n", strncmpW(str1, str2, sizeof(str2)/sizeof(str2[0])-1)); It outputs: strncmpW(str1, str2, sizeof(str2)/sizeof(str2[0])-1) = -115 So I'm what other cases I need to handle where strncmpW succeeds when it shouldn't. -- Rob Shearman

May 18, 2007

Re: mshtml: Change the binding flags when silent operation is requested by the DISPID_AMBIENT_SILENT property.

by Robert Shearman

Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > >> The binding flags should be have BINDF_SILENTOPERATION and BIND_NO_UI added. >> > > This breaks the tests: > > ../../../tools/runtest -q -P wine -M shdocvw.dll -T ../../.. -p shdocvw_test.exe.so webbrowser.c && touch webbrowser.ok > webbrowser.c:197: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL > make[2]: *** [webbrowser.ok] Error 1 I'm not sure how to fix that, so I'm going to have to drop the patch. -- Rob Shearman

May 18, 2007

Re: wininet: Add support for SSPI authentication for HTTP.

by Robert Shearman

Juan Lang wrote: > Hi Rob, > > +static UINT HTTP_DecodeBase64(LPCWSTR base64, LPSTR bin); > > Do we really have to keep proliferating base64 implementations? Could you > not implement CryptStringToBinaryW instead? Should be mostly a copy-paste > job.. > CryptStringToBinaryW is a lot more complicated than just a base64 encoder function, so this is beyond the scope of what I was trying to implement. I'll make a note to replace this code by CryptStringToBinaryW if someone does implement it though. -- Rob Shearman

May 18, 2007

Re: wininet: Add support for SSPI authentication for HTTP.

by Robert Shearman

Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > >> + if (strncmpiW(pszAuthValue, szBasic, sizeof(szBasic)/sizeof(szBasic[0])-1)) >> + { >> > > When using strncmp you need to also check that you reached the end of > the first string. > Hmm, it seems strncmpiW already does that for me so I'm a little confused: > int strncmpiW( const WCHAR *str1, const WCHAR *str2, int n ) > { > int ret = 0; > for ( ; n > 0; n--, str1++, str2++) > if ((ret = tolowerW(*str1) - tolowerW(*str2)) || !*str1) break; > return ret; > } >> + /* compare against last character to be set to avoid a race */ >> + if (HTTP_Base64Dec['/'] != 63) >> + { >> > > This won't avoid the race, you'll still get garbage if two threads get > here at the same time. Good spot, I'll fix this. -- Rob Shearman

May 18, 2007

New winetricks: added pdh, cc580; msxml3 now supports -q

by Dan Kegel

Thanks to Hans Leidekker for the pdh and common controls hunks! And thanks to Rob and James for whipping the msxml3 installer into shape; it now works even with -q. As always, it's up at http://kegel.com/wine/winetricks

May 17, 2007

Re: Wine keyboard driver+XKB. What am I to do?

by Vitaliy Margolen

Oleh R. Nykyforchyn wrote: > Hello, > I need an advice on what to do with some piece of code that I have written for > about 3 years. I started to make changes in Wine keyboard driver because I was If you would have cleaned it up and sent 3 years ago, then it would have been a part of the Wine for that long... What you should do is: 1. Remove all the useless changes (white space, debugging code, extra hacks all over the place). 2. Pick an indentation style either use the code's style or 4 spaces for indentation (not 3, not 5, and no tabs please). 3. Separate independent changes from everything else (additional layouts, layout table, structures, header files, different debug channel(s), noop changes) and send them separately to wine-patches. 4. Clean up the logic changing code and brake it into separate independent functions or logical parts that can be applied one after another (detect layouts, init keyboard, helper functions, etc). > In fact I made cosmetic changes to 3 files in winex11.drv directory: x11drv.h, > x11drv_main.c, event.c, but the fourth file keyboard.c was changed much more. > About half of functions in it were rewritten, and it now easier to read new > keyboard.c than diff output to understand the changes. Don't do cosmetic changes. This makes it impossible to see what the real changes are. Please remove all this type of changes from your patch. This will account for about 80% of all the changes. > I got very reasonable advice from L.Rahyen to broke the patch into smaller > parts. The problem is that I preserved the driver logic, but changed > data structures, so any such patch (even very small one) will touch hundreds if I didn't see all these hundreds of lines of code. I've seen 10-20 lines for each data structure change (not counting main_key_tab). Btw some of your structure changes are totally unnecessary and should be reverted (changes to event.c file). > lines across the whole file, probably introducing new bugs and being difficult > to read and understand. Also, there is no reason to change code by a patch Actually no. That would be the easiest thing to read - structure changes for each line. Nothing else. Thanks for working on this for such a long time and for all your hard work! I'm sure there are lots of people who really like to see this sort of functionality in Wine. Vitaliy.

May 17, 2007

Re: RegDeleteTree [4th] [resend]

by James Hawkins

On 5/17/07, Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: > Hello, > > is anything wrong with this patch? > +#if (_WIN32_WINNT >= 0x0600) +LONG WINAPI RegDeleteTreeA(HKEY,LPCSTR); +LONG WINAPI RegDeleteTreeW(HKEY,LPCWSTR); +#define RegDeleteTree WINELIB_NAME_AW(RegDeleteTree) +#endif /* (_WIN32_WINNT >= 0x0600) */ I don't think that's necessary. +static const WCHAR emptyW[] = {0}; You don't use this anywhere. + if (!ret) { You'll save a lot of indentation if you just return on error, for each error. -- James Hawkins

May 17, 2007

New Gecko package

by Luke Bratch

> I'm interested in > regressions, so just a simple test if app that worked before still works > will be fine. I've given it a test, and found the following: - When setting that URL in HKCU\Software\Wine\MSHTML, it will download but fail to install. - Extracting it to install it manually works, as do the scroll bars (which work fine) - It crashes after submitting more than one form on websites. For instance searching for something on Google, then searching again will cause a crash. This is with the latest git - wine-0.9.37-118-g2970076 ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

May 17, 2007

Re: Direct X 10 game demo

by Tom Spear

On 5/17/07, Michael Lothian <mike(a)fireburn.co.uk> wrote: > In my opinion games will check for DX version on Windows version. > Eventually once enough people have vista they will release DX10 on XP. > Probably about a month before the wine version is ready for XP. > > What do you guys think? Am I just being cynical? I think so. According to everything I have read DX10 is going to be tied in with the low level stuff even more so than DX9 was, and theres a lot of new low-level stuff for it to tie into that was not there with XP.. They would have to backport all of that stuff from Vista to XP, release it as either a Service Pack 3 or as XP Second Edition (groan), and then release DX10 for XP.. Now what they could/might do is offer a scaled down version of DX10 for XP, but there wouldnt be much real benefit over DX9.. Just SM4.0 etc -- Thanks Tom

May 17, 2007

debugging problem - winedbg: single stepping until exit from function, which has no line number information

by marcel busse

hello i'm on a project with wine but i can't get it debugged. not even a small hello world. here is the output of the hello world. My system opensuse 10.2 anyone help plz? Winedbg - Output: marcel(a)marcel-laptop-lan:~/prog/m5/m5/debug/src> winedbg m5.exe.so preloader: Warning: failed to reserve range 00000000-60000000 WineDbg starting on pid 000a 0x7b870749: movl %edi,0x0(%esp) Wine-dbg>step Single stepping until exit from function, which has no line number information. Invalid address (0x7b87074e) for breakpoint 0, disabling it Process of pid=000a has terminated Wine-dbg> Code: #ifdef HAVE_CONFIG_H #include <config.h> #endif #include <windows.h> int __stdcall WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) { MessageBox (NULL, "Hello, Windows!", "Hello", MB_OK); int test = 0; test = 1000; test += 100; return 0; } Configure-Output: cd '/home/marcel/prog/m5/m5/debug' && CC="winegcc" CXX="wineg++" LD="ld" CXXFLAGS="-O0 -gdwarf-2 -g3" "/home/marcel/prog/m5/m5/configure" --enable-debug=full checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether wineg++ accepts -g... yes checking for style of include used by make... GNU checking dependency style of wineg++... gcc3 checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for gcc... winegcc checking whether we are using the GNU C compiler... yes checking whether winegcc accepts -g... yes checking for winegcc option to accept ISO C89... none needed checking dependency style of winegcc... gcc3 checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by winegcc... ld checking if the linker (ld) is GNU ld... yes checking for ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... winegcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking how to run the C++ preprocessor... wineg++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from winegcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if winegcc supports -fno-rtti -fno-exceptions... no checking for winegcc option to produce PIC... -fPIC checking if winegcc PIC flag -fPIC works... yes checking if winegcc static flag -static works... no checking if winegcc supports -c -o file.o... yes checking whether the winegcc linker (ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by wineg++... ld checking if the linker (ld) is GNU ld... yes checking whether the wineg++ linker (ld) supports shared libraries... yes checking for wineg++ option to produce PIC... -fPIC checking if wineg++ PIC flag -fPIC works... yes checking if wineg++ static flag -static works... no checking if wineg++ supports -c -o file.o... yes checking whether the wineg++ linker (ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands *** Erfolg *** Make Output: cd '/home/marcel/prog/m5/m5/debug/src' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake m5 if wineg++ -DHAVE_CONFIG_H -I. -I/home/marcel/prog/m5/m5/src -I.. -O0 -gdwarf-2 -g3 -MT m5.o -MD -MP -MF ".deps/m5.Tpo" -c -o m5.o /home/marcel/prog/m5/m5/src/m5.cpp; then mv -f ".deps/m5.Tpo" ".deps/m5.Po"; else rm -f ".deps/m5.Tpo"; exit 1; fi /bin/sh ../libtool --tag=CXX --mode=link wineg++ -O0 -gdwarf-2 -g3 -o m5 -mwindows m5.o wineg++ -O0 -gdwarf-2 -g3 -o m5 -mwindows m5.o *** Erfolg *** --------------------------------- Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever.

May 17, 2007

Re: hnetcfg: [3/8] uuids for INetFwMgr interface

by Jeff L

For dlls, should the GUID's be put in uuids.h or kept local to the dll. In this case I don't think anything else cares about them, so they could be local. Jeff Latimer Jeff Latimer wrote: > Add public uuids for the interface. > > ------------------------------------------------------------------------ > > diff --git a/include/uuids.h b/include/uuids.h > +OUR_GUID_ENTRY(IID_INetFwMgr, 0xf7898af5, 0xcac4, 0x4632, 0xa2, 0xec, 0xda ,0x06, 0xe5, 0x11, 0x1a, 0xf2) > +OUR_GUID_ENTRY(CLSID_NetFwMgr, 0x304ce942, 0x6e39, 0x40d8, 0x94, 0x3a, 0xb9, 0x13, 0xc4, 0x0c, 0x9c, 0xd4) >

May 17, 2007

Re: msxml3 [2/6]: Add initial implementation of IXMLElement

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > Changelog: > * Add initial implementation of IXMLElement. > > dlls/msxml3/Makefile.in | 1 + > dlls/msxml3/msxml_private.h | 2 + > dlls/msxml3/xmlelem.c | 426 ++++++++++++++++++++++++++++++++++++++ > dlls/msxml3/xmlelem_collection.c | 41 ++++- It's suggest to put everything inside xmlelem.c, there's no need to create a new file for every interface. -- Alexandre Julliard julliard(a)winehq.org

May 17, 2007

New Gecko package

by Jacek Caban

Hi all, It's time to update our Gecko package. I've prepared a new one. I'd like to avoid any regression, esp. ones that would require changing the package again. That's why I'd like to do a good test. I'm interested in regressions, so just a simple test if app that worked before still works will be fine. To do so download: http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko.tar.bz2 1) if you already have installed Gecko, simply extract the package and replace c:\windows\wine_gecko with it. 2) otherwise extract the package and set GeckoPath variable of HKCU\Software\Winde\MSHTML registry key to its location. Then run an app and check if it still works. Note that you have to use current Git, older Wine is not compatible with the new Gecko. Expected visible difference should be: - Working scrollbars (still not perfect, they will be visible even if app sets it to not be, but it's better than before - I will work on it later) - Pages that require plugins will render like there was no plugin instead of offering downloading one (that doesn't work anyway) >From technical point of view this version differs much from previous one. Previous version was just a SeaMonkey with manually removed and changed some files. This one is my built from source (I will create a page on wiki about how to do so). It's based on XUL Runner 1.8.1.3, which has the same source as Firefox 2.0.0.3. After testing it, I will change Gecko installer a bit to be able to deal with different Gecko versions for different Wine version and upload it to SourceForge. Thanks, Jacek

May 17, 2007

Re: Set background image for virtual desktop

by Hans Leidekker

On Thursday 17 May 2007 07:41:58 Vijay Kiran Kamuju wrote: > Is it possible to set background image for the virtual desktop in wine? > If so how do we set it? (I am bored see same old single color virtual > desktop ;) ) Here's a starting point: dlls/user32/desktop.c:SetDeskWallPaper() -Hans

May 17, 2007

Re: ntoskrnl.exe: Import MSVCRT which we are forwarding to.

by James Hawkins

On 5/17/07, Saulius Krasuckas <saulius.krasuckas(a)ieee.org> wrote: > I am testing "Microsoft Virtual CD-ROM Control Panel" from [*]. It > searches for "msvcrt._local_unwind2" and "msvcrt._except_handler3", but > doesn't find them and then makes stack overflow: > > 000d:trace:loaddll:load_native_dll Loaded module L"Z:\\mnt\\antras\\usr\\src\\wine-git\\VCDxp\\VCdRom.sys" : native > 000d:trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ntoskrnl.exe" : builtin > 000d:err:module:find_forwarded_export module not found for forward 'msvcrt._local_unwind2' used by L"c:\\windows\\system32\\ntoskrnl.exe" > 000d:err:module:find_forwarded_export module not found for forward 'msvcrt._except_handler3' used by L"c:\\windows\\system32\\ntoskrnl.exe" > 000d:trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\hal.dll" : builtin > 000d:trace:process:set_entry_point setting FT_Thunk at 0x7b8ac080 to 00000000 > 000d:trace:loaddll:MODULE_LoadModule16 Loaded module "krnl386.exe" : builtin > 000d:trace:loaddll:MODULE_LoadModule16 Loaded module "system.drv" : builtin > 000d:trace:ntoskrnl:IoCreateDevice (0x7ffdf000, 48, L"\\Device\\VirtualCdRom", 2, 3, 0, 0x34fee8) > wine: Call from 0x7b840d20 to unimplemented function ntoskrnl.exe.ExAllocatePoolWithTag, aborting > wine: Call from 0x7bc56dd5 to unimplemented function ntoskrnl.exe._except_handler3, aborting > wine: Call from 0x7bc56dd5 to unimplemented function ntoskrnl.exe._except_handler3, aborting > wine: Call from 0x7bc56dd5 to unimplemented function ntoskrnl.exe._except_handler3, aborting > ... > > Could that be a simple typo in Makefile.in? > > This is from bug 8408: ------- Additional Comments From julliard(a)winehq.com 2007-16-05 12:17 ------- That stuff is not supposed to work yet. ntoskrnl needs to be loaded from a service process that will take care of importing msvcrt. Currently the driver is executed directly which cannot work. -- James Hawkins

May 17, 2007

Re: ntoskrnl.exe: Import MSVCRT which we are forwarding to.

by Alexandre Julliard

Saulius Krasuckas <saulius.krasuckas(a)ieee.org> writes: > Could that be a simple typo in Makefile.in? No, it's deliberate. Importing msvcrt here will cause lots of trouble, it will be imported in the process that loads the driver. -- Alexandre Julliard julliard(a)winehq.org

May 17, 2007

Re: ntoskrnl.exe: Implemented IoCreateSymbolicLink

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > How are you planning on removing them if you don't keep a handle to this > symlink? Yes, obviously the handle will need to be stored to remove it, that's why there's a FIXME. Since it will be removed automatically on driver unload, it's not the most important thing to implement at this point. > Also why OBJ_CASE_INSENSITIVE? This is kernel, and last time > I've checked NT kernel's name space was case-sensitive. No particular reason, I just copied this from some other object. I doubt it makes a difference but if you have evidence that it should be case sensitive here feel free to send a patch. -- Alexandre Julliard julliard(a)winehq.org

May 17, 2007

Set background image for virtual desktop

by Vijay Kiran Kamuju

Hi, Is it possible to set background image for the virtual desktop in wine? If so how do we set it? (I am bored see same old single color virtual desktop ;) ) Cheers, VJ PS: ----- Any new areas I could work on since d3drm work is complete

May 17, 2007

Re: ntoskrnl.exe: Implemented IoCreateSymbolicLink

by Vitaliy Margolen

Alexandre Julliard wrote: > + attr.Attributes = OBJ_CASE_INSENSITIVE | OBJ_OPENIF; > + attr.SecurityDescriptor = NULL; > + attr.SecurityQualityOfService = NULL; > + > + TRACE( "%s -> %s\n", debugstr_us(name), debugstr_us(target) ); > + /* FIXME: store handle somewhere */ > + return NtCreateSymbolicLinkObject( &handle, SYMBOLIC_LINK_ALL_ACCESS, &attr, target ); How are you planning on removing them if you don't keep a handle to this symlink? Also why OBJ_CASE_INSENSITIVE? This is kernel, and last time I've checked NT kernel's name space was case-sensitive. Vitaliy.

May 16, 2007

Bug 219 and some bugzilla in general.

by Vitaliy Margolen

Is it just me or did anyone else have a feeling that our bugilla turned into some kind of forum by selected individuals? I understand all the excitement from this new shiny ntoskrnl, but what _exactly_ does it have to do with safedisk in general? And what all the "other" apps this person claims that ntoskrnl is too limited to support? What's that have to do with bug 219?! Please if you post information to bugzilla, discuss the bug related matters *only*. All general stuff should go here! And unless you have any useful information to provide that will help the resolution of the bug, don't! And the reason this bug is still the only bug open for safedisk, is because Wine still a long way away from running _any_ safedisk protected game (of course I'm talking about 1.2+ versions that do have kernel driver). I'm sorry, but please can we use things in the way they were meant to be used? Vitaliy > ------- Additional Comments From ead1234(a)hotmail.com 2007-16-05 20:20 ------- > ntoskrnl.exe has been added to wine now, though it may not be ready to handle > safedisc v1 as of yet there are several versions of safedisc and other > technologies and once safedisc 1.0 is supported there will be hundreds of other > apps that don't work with later versions of safedisc and other copy protection > technologies. 1 catch-all bug is hardly sufficient to deal with all the > bugs/limitations of ntoskrnl.exe that will eventually arise as not all copyright > technologies are going to fault at the same point in ntoskrnl and other areas of > wine. Is it not time to add an ntoskrnl component now that it has been partially > implemented in wine, especially for the safedisc 2+ versions that won't work > after this initial wave of stubs? >

May 16, 2007

Re: [PATCH 4/8, try3] msi: automation: Implement Installer::ProductInfo.

by Misha Koshelev

On Wed, 2007-05-16 at 17:23 +0200, Michael Stefaniuc wrote: > Misha Koshelev wrote: > > On Wed, 2007-05-16 at 15:33 +0200, Alexandre Julliard wrote: > >> Misha Koshelev <mk144210(a)bcm.edu> writes: > >> > >>> --- > >>> dlls/msi/automation.c | 36 +++++++++++++++++++- > >>> dlls/msi/msiserver.idl | 4 ++ > >>> dlls/msi/msiserver_dispids.h | 1 + > >>> dlls/msi/tests/automation.c | 74 ++++++++++++++++++++---------------------- > >> This one fails make test for me: > >> > >> ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so automation.c && touch automation.ok > >> automation.c:1944: Test failed: Installer_ProductInfo failed, hresult 0x00000000 > >> make[2]: *** [automation.ok] Error 1 > >> > > > > Hmm... works for me but let me try doing a make clean; make depend; make > > on all of wine to make sure something somewhere else has not changed > > that changed its behavior. > Sometimes you even need to remove your .wine directory too. Not that the > tests assume something is already present in the enviroment. > > bye > michael Alright, I think I know what's going on. I will submit some new patches. Misha

May 16, 2007

New Gecko package

by Jacek Caban

Hi all, It's time to update our Gecko package. I've prepared a new one. I'd like to avoid any regression, esp. ones that would require changing the package again. That's why I'd like to do a good test. I'm interested in regressions, so just a simple test if app that worked before still works will be fine. To do so download: http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko.tar.bz2 1) if you already have installed Gecko, simply extract the package and replace c:\windows\wine_gecko with it. 2) otherwise extract the package and set GeckoPath variable of HKCU\Software\Winde\MSHTML registry key to its location. Then run an app and check if it still works. Note that you have to use current Git, older Wine is not compatible with the new Gecko. Expected visible difference should be: - Working scrollbars (still not perfect, they will be visible even if app sets it to not be, but it's better than before - I will work on it later) - Pages that require plugins will render like there was no plugin instead of offering downloading one (that doesn't work anyway) >From technical point of view this version differs much from previous one. Previous version was just a SeaMonkey with manually removed and changed some files. This one is my built from source (I will create a page on wiki about how to do so). It's based on XUL Runner 1.8.1.3, which has the same source as Firefox 2.0.0.3. After testing it, I will change Gecko installer a bit to be able to deal with different Gecko versions for different Wine version and upload it to SourceForge. Thanks, Jacek

May 16, 2007

Re: Direct X 10 game demo

by Tom Spear

On 5/16/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > <snip> Past that I don't see any > > reason why they would code additional version checks after that. All > > the games that I've seen don't do that. > > <snip> > > I don't see a reason why it needs* to check > > the version of windows. > Those are windows apps, keep that in mind ;-) Never expect sane behavior from > them :-) So true ;-) Unfortunately, like I said MS is not making DX10 compatible with XP, which really sucks because imo Vista is the biggest piece (of junk) ever and I personally _probably_ wont 'upgrade' my windows machine to it even after Service Pack 2 comes out. So since MS is going to do that, I expect to see a lot of games (at least at the beginning) that have compatibility code, where it checks the windows version at start to determine whether to run in dx10 mode, or not, due to windows users who upgrade and dont reinstall their apps. -- Thanks Tom

May 16, 2007

Re: Direct X 10 game demo

by Stefan Dösinger

> <snip> Past that I don't see any > reason why they would code additional version checks after that. All > the games that I've seen don't do that. > <snip> > I don't see a reason why it needs* to check > the version of windows. Those are windows apps, keep that in mind ;-) Never expect sane behavior from them :-)

May 16, 2007

Re: Direct X 10 game demo

by Kovács András

This game isn't check windows version on installing. 2007. május 16. 20.32 dátummal Jesse Allen ezt írta: > On 5/16/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > Am Mittwoch 16 Mai 2007 16:25 schrieb Tom Spear: > > > On 5/15/07, EA Durbin <ead1234(a)hotmail.com> wrote: > > > > The lost planet demo utilizing Direct X 10 is out, for those of you > > > > interested in developing/testing Direct X 10. > > > > > > I'm curious. When we do start work on DX10, are we going to set it up > > > so that it will only work if the user uses winver ~= vista or greater, > > > or will it be available for all winvers that are capable of supporting > > > it? > > > > > > I'd like to see (a few years from now obviously), if it would be > > > possible to use wine's directx to play a dx10 game on winxp, since Ms > > > is not going to make dx10 for xp.. > > > > I don't think we'll have an artificial winver=winvista in our d3d10 code, > > unless an application fails because it finds a working d3d10 on a > > supposed windows xp. And even then we can port it to real xp without that > > check > > I think that it's highly more likely that the game will check the > windows version the standard way at install. So as long as you pass > the version check there you'll be fine. Past that I don't see any > reason why they would code additional version checks after that. All > the games that I've seen don't do that. > > If the game is standalone or runs without installing, then it would > probably just try to create the standard DX10 object that it needs. If > we provide it, then it will try to run. If not it will probably say it > needs DX10 or something. I don't see a reason why it needs* to check > the version of windows. > > *But just you wait someone is bound to do it... > > Jesse -- ---------------------------- Kovács András (andras) NetClub Vezető Rendszergazda Lamarr csevego.net andras(a)csevego.net ----------------------------

May 16, 2007

Wine keyboard driver+XKB. What am I to do?

by Oleh R. Nykyforchyn

Hello, I need an advice on what to do with some piece of code that I have written for about 3 years. I started to make changes in Wine keyboard driver because I was not able to use MS Office under it on my Linux box (3 or 4 XKB groups, 2 overlay groups used, English, Russian, Ukrainian, Belarusian, German and Polish layouts). First I submitted a patch that adds koi8-u encoding to Wine, and it was happily introduced. But my changes to X11DRV (now winex11) keyboard driver were large and I understand Wine people who didn't want to risk. Meanwhile I continued to polish my implementation to correct bugs and improve performance. I am heavily indebted to people that tested my patches, wrote me about problems with them and suggested possible solutions. I thank to L.Rahyen that supported me in my efforts. Now patched keyboard driver allows user to: 1) have up to 4 XKB groups working (current code uses 1 or 2); 2) detect and use XKB overlays to put 2 or 3 close layouts (e.g. Russian, Ukrainian and Belarusian) into one XKB group; 3) freely combine available XKB layouts in any order, e.g. "en,ru,fr"; 4) list all layouts available at the system, and implement ActivateKeyboardLayout(); 5) notify an application (e.g. MS Word) about change of layout, and make GetKeyboardLayout() work really, not just return LCID for current locale of Unix box; 6) input characters that do not fit into current Unix locale, e.g. German and French accented letters at a system with Cyrillic (not UTF) locale; 7) override any of detected layouts via registry, if user is not satisfied with Wine driver choice. In fact I made cosmetic changes to 3 files in winex11.drv directory: x11drv.h, x11drv_main.c, event.c, but the fourth file keyboard.c was changed much more. About half of functions in it were rewritten, and it now easier to read new keyboard.c than diff output to understand the changes. I got very reasonable advice from L.Rahyen to broke the patch into smaller parts. The problem is that I preserved the driver logic, but changed data structures, so any such patch (even very small one) will touch hundreds if lines across the whole file, probably introducing new bugs and being difficult to read and understand. Also, there is no reason to change code by a patch if we can benefit of it only after next patch. Now I will be grateful to any help. How can such big changes be introduced in Wine tree? I also attach a patch against wine-0.9.37 and copies of original and changed files. Perhaps somebody, who is interested in multilingual keyboard input, can test it and write me about results. Oleh

May 16, 2007

Re: Direct X 10 game demo

by Jesse Allen

On 5/16/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Mittwoch 16 Mai 2007 16:25 schrieb Tom Spear: > > On 5/15/07, EA Durbin <ead1234(a)hotmail.com> wrote: > > > The lost planet demo utilizing Direct X 10 is out, for those of you > > > interested in developing/testing Direct X 10. > > > > I'm curious. When we do start work on DX10, are we going to set it up > > so that it will only work if the user uses winver ~= vista or greater, > > or will it be available for all winvers that are capable of supporting > > it? > > > > I'd like to see (a few years from now obviously), if it would be > > possible to use wine's directx to play a dx10 game on winxp, since Ms > > is not going to make dx10 for xp.. > I don't think we'll have an artificial winver=winvista in our d3d10 code, > unless an application fails because it finds a working d3d10 on a supposed > windows xp. And even then we can port it to real xp without that check > I think that it's highly more likely that the game will check the windows version the standard way at install. So as long as you pass the version check there you'll be fine. Past that I don't see any reason why they would code additional version checks after that. All the games that I've seen don't do that. If the game is standalone or runs without installing, then it would probably just try to create the standard DX10 object that it needs. If we provide it, then it will try to run. If not it will probably say it needs DX10 or something. I don't see a reason why it needs* to check the version of windows. *But just you wait someone is bound to do it... Jesse

May 16, 2007

Re: Direct X 10 game demo

by Stefan Dösinger

Am Mittwoch 16 Mai 2007 16:25 schrieb Tom Spear: > On 5/15/07, EA Durbin <ead1234(a)hotmail.com> wrote: > > The lost planet demo utilizing Direct X 10 is out, for those of you > > interested in developing/testing Direct X 10. > > I'm curious. When we do start work on DX10, are we going to set it up > so that it will only work if the user uses winver ~= vista or greater, > or will it be available for all winvers that are capable of supporting > it? > > I'd like to see (a few years from now obviously), if it would be > possible to use wine's directx to play a dx10 game on winxp, since Ms > is not going to make dx10 for xp.. I don't think we'll have an artificial winver=winvista in our d3d10 code, unless an application fails because it finds a working d3d10 on a supposed windows xp. And even then we can port it to real xp without that check

May 16, 2007

Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab

by Frank Richter

On 16.05.2007 18:18, Frank Richter wrote: > I would make the combobox editable (plain CBS_DROPDOWN), Er, you do that already. Pays off to read... > just add all > "preset" memory sizes, and WM_SETTEXT the value read from the registry. Might be code-wise a bit simpler than your GETCURSEL approach, but otherswise not much different I think. -f.r.

May 16, 2007

Re: [PATCH 4/8, try3] msi: automation: Implement Installer::ProductInfo.

by Misha Koshelev

On Wed, 2007-05-16 at 17:23 +0200, Michael Stefaniuc wrote: > Misha Koshelev wrote: > > On Wed, 2007-05-16 at 15:33 +0200, Alexandre Julliard wrote: > >> Misha Koshelev <mk144210(a)bcm.edu> writes: > >> > >>> --- > >>> dlls/msi/automation.c | 36 +++++++++++++++++++- > >>> dlls/msi/msiserver.idl | 4 ++ > >>> dlls/msi/msiserver_dispids.h | 1 + > >>> dlls/msi/tests/automation.c | 74 ++++++++++++++++++++---------------------- > >> This one fails make test for me: > >> > >> ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so automation.c && touch automation.ok > >> automation.c:1944: Test failed: Installer_ProductInfo failed, hresult 0x00000000 > >> make[2]: *** [automation.ok] Error 1 > >> > > > > Hmm... works for me but let me try doing a make clean; make depend; make > > on all of wine to make sure something somewhere else has not changed > > that changed its behavior. > Sometimes you even need to remove your .wine directory too. Not that the > tests assume something is already present in the enviroment. > > bye > michael Alright, I am afraid I am stumped here. I simply cannot reproduce Alexandre's error. I have done a ./configure --prefix=/usr; make clean; make depend; make; sudo make install and removed my ~/.wine and everything still works hunky dory with the patch (and of course I did a git fetch; git rebase origin first). If anyone else could try applying it to their git tree, doing a make and sudo make install in dlls/msi, wineprefixcreate (because IDL defns have to be updated in the fake DLLs in the ~/.wine directory), and then make automation.ok in the dlls/msi/tests directory and let me know if it works for them that would be great. I've attached the patch to the current git head below. It is the same as the one on the wine-devel list except I've set my emacs to use spaces now instead of tabs (and diff -w shows no differences except the headers). Thanks Misha

May 16, 2007

Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab

by Frank Richter

I would make the combobox editable (plain CBS_DROPDOWN), just add all "preset" memory sizes, and WM_SETTEXT the value read from the registry. -f.r.

May 16, 2007

Re: [PATCH 4/8, try3] msi: automation: Implement Installer::ProductInfo.

by Michael Stefaniuc

Misha Koshelev wrote: > On Wed, 2007-05-16 at 15:33 +0200, Alexandre Julliard wrote: >> Misha Koshelev <mk144210(a)bcm.edu> writes: >> >>> --- >>> dlls/msi/automation.c | 36 +++++++++++++++++++- >>> dlls/msi/msiserver.idl | 4 ++ >>> dlls/msi/msiserver_dispids.h | 1 + >>> dlls/msi/tests/automation.c | 74 ++++++++++++++++++++---------------------- >> This one fails make test for me: >> >> ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so automation.c && touch automation.ok >> automation.c:1944: Test failed: Installer_ProductInfo failed, hresult 0x00000000 >> make[2]: *** [automation.ok] Error 1 >> > > Hmm... works for me but let me try doing a make clean; make depend; make > on all of wine to make sure something somewhere else has not changed > that changed its behavior. Sometimes you even need to remove your .wine directory too. Not that the tests assume something is already present in the enviroment. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

May 16, 2007

Re: [PATCH 4/8, try3] msi: automation: Implement Installer::ProductInfo.

by Misha Koshelev

On Wed, 2007-05-16 at 15:33 +0200, Alexandre Julliard wrote: > Misha Koshelev <mk144210(a)bcm.edu> writes: > > > --- > > dlls/msi/automation.c | 36 +++++++++++++++++++- > > dlls/msi/msiserver.idl | 4 ++ > > dlls/msi/msiserver_dispids.h | 1 + > > dlls/msi/tests/automation.c | 74 ++++++++++++++++++++---------------------- > > This one fails make test for me: > > ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so automation.c && touch automation.ok > automation.c:1944: Test failed: Installer_ProductInfo failed, hresult 0x00000000 > make[2]: *** [automation.ok] Error 1 > Hmm... works for me but let me try doing a make clean; make depend; make on all of wine to make sure something somewhere else has not changed that changed its behavior. Misha

May 16, 2007

Re: Direct X 10 game demo

by Tom Spear

On 5/15/07, EA Durbin <ead1234(a)hotmail.com> wrote: > The lost planet demo utilizing Direct X 10 is out, for those of you > interested in developing/testing Direct X 10. I'm curious. When we do start work on DX10, are we going to set it up so that it will only work if the user uses winver ~= vista or greater, or will it be available for all winvers that are capable of supporting it? I'd like to see (a few years from now obviously), if it would be possible to use wine's directx to play a dx10 game on winxp, since Ms is not going to make dx10 for xp.. -- Thanks Tom

May 16, 2007

Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab

by Laurent Vromman

It is not really as I wish. I have just noticed that there is two different kind of indentation in the mentioned switch loop, which looked strange on the moment. I am really not a wine master, others will maybe fixed us. Laurent On Wed, 16 May 2007 15:59:06 +0200, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> wrote: > On Wed, May 16, 2007 at 03:18:22PM +0200, Laurent Vromman wrote: >> case CBN_SELCHANGE: { >> SendMessage(GetParent(hDlg), PSM_CHANGED, 0, 0); >> switch (LOWORD(wParam)) { >> - case IDC_D3D_VSHADER_MODE: on_d3d_vshader_mode_changed(hDlg); > break; >> - } >> + case IDC_D3D_VSHADER_MODE: > on_d3d_vshader_mode_changed(hDlg); break; >> + case IDC_VIDEOMEMORY_SIZE_COMBO: > set_from_videomemory_size_changed(hDlg); break; >> + } >> >> I believe you should align your indentation method on the one the file > already uses (ie tabs, not spaces). >> >> +// vim:sw=4:expandtab >> >> This has nothing to do with wine >> >> Laurent > > Hi Laurent > citing from: http://www.winehq.org/site/docs/winedev-guide/style-notes > "Tabs are not forbidden but discouraged. A tab is defined as 8 > characters and the usual amount of indentation is 4 characters." > > and from: http://www.winehq.org/site/sending_patches > "Don't mix tabs and spaces because it makes the diff output > unreadable, use consistent indentation." > > The actual file contents breaks both citations above, my code doesn't > conflict with any one of them. > > For vim footer, I agree it shall not be present. If the only comment > regards formatting, I'm happy and I can fix the formatting as You wish. > > Cheers > Vit

May 16, 2007

Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab

by Vit Hrachovy

On Wed, May 16, 2007 at 03:18:22PM +0200, Laurent Vromman wrote: > case CBN_SELCHANGE: { > SendMessage(GetParent(hDlg), PSM_CHANGED, 0, 0); > switch (LOWORD(wParam)) { > - case IDC_D3D_VSHADER_MODE: on_d3d_vshader_mode_changed(hDlg); break; > - } > + case IDC_D3D_VSHADER_MODE: on_d3d_vshader_mode_changed(hDlg); break; > + case IDC_VIDEOMEMORY_SIZE_COMBO: set_from_videomemory_size_changed(hDlg); break; > + } > > I believe you should align your indentation method on the one the file already uses (ie tabs, not spaces). > > +// vim:sw=4:expandtab > > This has nothing to do with wine > > Laurent Hi Laurent citing from: http://www.winehq.org/site/docs/winedev-guide/style-notes "Tabs are not forbidden but discouraged. A tab is defined as 8 characters and the usual amount of indentation is 4 characters." and from: http://www.winehq.org/site/sending_patches "Don't mix tabs and spaces because it makes the diff output unreadable, use consistent indentation." The actual file contents breaks both citations above, my code doesn't conflict with any one of them. For vim footer, I agree it shall not be present. If the only comment regards formatting, I'm happy and I can fix the formatting as You wish. Cheers Vit

May 16, 2007

Re: mshtml: Change the binding flags when silent operation is requested by the DISPID_AMBIENT_SILENT property.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > The binding flags should be have BINDF_SILENTOPERATION and BIND_NO_UI added. This breaks the tests: ../../../tools/runtest -q -P wine -M shdocvw.dll -T ../../.. -p shdocvw_test.exe.so webbrowser.c && touch webbrowser.ok webbrowser.c:197: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL make[2]: *** [webbrowser.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

May 16, 2007

Re: [PATCH 4/8, try3] msi: automation: Implement Installer::ProductInfo.

by Alexandre Julliard

Misha Koshelev <mk144210(a)bcm.edu> writes: > --- > dlls/msi/automation.c | 36 +++++++++++++++++++- > dlls/msi/msiserver.idl | 4 ++ > dlls/msi/msiserver_dispids.h | 1 + > dlls/msi/tests/automation.c | 74 ++++++++++++++++++++---------------------- This one fails make test for me: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so automation.c && touch automation.ok automation.c:1944: Test failed: Installer_ProductInfo failed, hresult 0x00000000 make[2]: *** [automation.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

May 16, 2007

Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab

by Laurent Vromman

case CBN_SELCHANGE: { SendMessage(GetParent(hDlg), PSM_CHANGED, 0, 0); switch (LOWORD(wParam)) { - case IDC_D3D_VSHADER_MODE: on_d3d_vshader_mode_changed(hDlg); break; - } + case IDC_D3D_VSHADER_MODE: on_d3d_vshader_mode_changed(hDlg); break; + case IDC_VIDEOMEMORY_SIZE_COMBO: set_from_videomemory_size_changed(hDlg); break; + } I believe you should align your indentation method on the one the file already uses (ie tabs, not spaces). +// vim:sw=4:expandtab This has nothing to do with wine Laurent On Wed, 16 May 2007 15:03:52 +0200, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> wrote: > Hi, > the attached patch adds new editable combobox input 'Video Memory size' > for Graphics/Direct3D tab of winecfg. > > I've tried to implement Frank's comments to English language only. > Please consider this patch as a proposal, so if it gets positive review, > I'll propagate the changes to all remaining language resources. > > May I kindly ask someone for the patch review? > Regards > Vit > >

May 16, 2007

review: add Video Memory text input to winecfg Graphics/Direct3D tab

by Vit Hrachovy

Hi, the attached patch adds new editable combobox input 'Video Memory size' for Graphics/Direct3D tab of winecfg. I've tried to implement Frank's comments to English language only. Please consider this patch as a proposal, so if it gets positive review, I'll propagate the changes to all remaining language resources. May I kindly ask someone for the patch review? Regards Vit

May 16, 2007

Re: ADVAPI32: Fix return value to indicate error when NULL string is passed in

by Alexandre Julliard

Rolf Kalbermatter <r.kalbermatter(a)hccnet.nl> writes: > - if (ret) > + if (ret || (!lpDisplayName && size)) > { > if (lpDisplayName && *lpcchBuffer) *lpDisplayName = 0; > > - if (ret == ERROR_MORE_DATA) > + if ((!ret && !lpDisplayName) || ret == ERROR_MORE_DATA) These complex conditions make it really hard to figure out what the code is doing. You should probably handle the NULL pointer as a separate case. -- Alexandre Julliard julliard(a)winehq.org

May 16, 2007

Re: winscard stub dll

by Mounir IDRASSI

Hi Francois, Thanks for your modifications. I'll review your patch and submit it if I have no comments, ِCheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Francois Gouget wrote: > Hi, > > Here's a new version of the patch that removes the casts as suggested > by Alexandre. >

May 16, 2007

Re: [PATCH 3/6] CMD.EXE: Handle command line as Unicode

by Dmitry Timoshkov

"Jason Edmeades" <us(a)edmeades.me.uk> wrote: > int main (int argc, char *argv[]) > { > + LPWSTR *argvW = NULL; > + int args; > + WCHAR *cmdW = NULL; If you will start using wmain() instead of main() you get unicode args for free, and that will help to avoid changing the command line parsing code. -- Dmitry.

May 15, 2007

Direct X 10 game demo

by EA Durbin

The lost planet demo utilizing Direct X 10 is out, for those of you interested in developing/testing Direct X 10. http://www.fileshack.com/file.x/10513/Lost+Planet:+Extreme+Condition+Demo+-… _________________________________________________________________ Make every IM count. Download Messenger and join the im Initiative now. Its free. http://im.live.com/messenger/im/home/?source=TAGHM_MAY07

May 15, 2007

Re: winscard stub dll

by Francois Gouget

Hi, Mounir IDRASSI wrote: > Hi, > Apart from Alexandre comment, I don't see any other possible changes. Here's a new version of the patch that removes the casts as suggested by Alexandre. -- Francois Gouget fgouget(a)codeweavers.com

May 15, 2007

Re: [PATCH 1/6] msi: automation: Condense a few loops.

by Misha Koshelev

On Tue, 2007-05-15 at 16:35 -0500, James Hawkins wrote: > On 5/15/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > > --- > > dlls/msi/automation.c | 30 ++++++++++++------------------ > > 1 files changed, 12 insertions(+), 18 deletions(-) > > > > --- a/dlls/msi/automation.c > > +++ b/dlls/msi/automation.c > > @@ -580,16 +580,13 @@ static HRESULT WINAPI RecordImpl_Invoke( > > if (FAILED(hr)) return hr; > > V_VT(pVarResult) = VT_BSTR; > > V_BSTR(pVarResult) = NULL; > > - ret = MsiRecordGetStringW(This->msiHandle, V_I4(&varg0), NULL, &dwLen); > > - if (ret == ERROR_SUCCESS) > > + if ((ret = MsiRecordGetStringW(This->msiHandle, V_I4(&varg0), NULL, > &dwLen)) == ERROR_SUCCESS) > > { > > Did you mean to mix tabs and spaces in your own file? You should > probably stick with one or the other (preferably spaces to keep with > the rest of msi). > Will do spaces to conform with rest of msi. Misha

May 15, 2007

ntoskrnl.exe: Initial stub version with forwards to existing functions.

by EA Durbin

Nice! : ) _________________________________________________________________ PC Magazines 2007 editors choice for best Web mailaward-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migrati…

May 15, 2007

Re: [PATCH 2/6] msi/tests: automation: Remove unnecessary if (SUCCEEDED(hr)) statements.

by Jacek Caban

Hi Misha, While you are at it, it's worth to directly compare the result to S_OK in tests instead of using SUCCEEDED macro as it's a more strict test. Jacek

May 15, 2007

Re: wined3d: Add hardware cursor support.

by Stefan Dösinger

Am Dienstag 15 Mai 2007 00:40 schrieb Andrew Riedi: > Ok, I think the patch is finally ready to go in. I applied what Stefan > wanted me to apply. > > changelog: wined3d: Add hardware cursor support. Looks ok to me

May 15, 2007

Re: [PATCH 1/6] msi: automation: Condense a few loops.

by James Hawkins

On 5/15/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > --- > dlls/msi/automation.c | 30 ++++++++++++------------------ > 1 files changed, 12 insertions(+), 18 deletions(-) > --- a/dlls/msi/automation.c +++ b/dlls/msi/automation.c @@ -580,16 +580,13 @@ static HRESULT WINAPI RecordImpl_Invoke( if (FAILED(hr)) return hr; V_VT(pVarResult) = VT_BSTR; V_BSTR(pVarResult) = NULL; - ret = MsiRecordGetStringW(This->msiHandle, V_I4(&varg0), NULL, &dwLen); - if (ret == ERROR_SUCCESS) + if ((ret = MsiRecordGetStringW(This->msiHandle, V_I4(&varg0), NULL, &dwLen)) == ERROR_SUCCESS) { Did you mean to mix tabs and spaces in your own file? You should probably stick with one or the other (preferably spaces to keep with the rest of msi). -- James Hawkins

May 15, 2007

Re: wininet: Add support for SSPI authentication for HTTP.

by Juan Lang

Hi Rob, +static UINT HTTP_DecodeBase64(LPCWSTR base64, LPSTR bin); Do we really have to keep proliferating base64 implementations? Could you not implement CryptStringToBinaryW instead? Should be mostly a copy-paste job.. --Juan ____________________________________________________________________________________Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php

May 15, 2007

Re: wininet: Add support for SSPI authentication for HTTP.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > + if (strncmpiW(pszAuthValue, szBasic, sizeof(szBasic)/sizeof(szBasic[0])-1)) > + { When using strncmp you need to also check that you reached the end of the first string. > + /* compare against last character to be set to avoid a race */ > + if (HTTP_Base64Dec['/'] != 63) > + { This won't avoid the race, you'll still get garbage if two threads get here at the same time. -- Alexandre Julliard julliard(a)winehq.org

May 15, 2007

Re: winscard stub dll

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > But then on a 64bit system an __int64 should be the same as a long so > maybe it's ok anyway. Yes, __int64 is a long on Win64. > The only issue that could happen is if we try to compile Wine's dlls > on a 64bit Windows system using Visual C++. Isn't a long 32bit in > Visual C++? Is this a case we care about? No we don't really care, but anyway I don't think Visual C++ is smart enough to warn on printf formats. -- Alexandre Julliard julliard(a)winehq.org

May 15, 2007

Re: winscard stub dll

by Francois Gouget

Alexandre Julliard wrote: > Francois Gouget <fgouget(a)codeweavers.com> writes: > >> * I would really have liked to get rid of the (unsigneg int) casts, but >> as the handle types are ULONG_PTRs it seems like it won't be possible. >> That's quite annoying. If anyone has suggestions... > > ULONG_PTRs are longs, they should be printed with %lx without casts. On 32bit systems yes, but not on 64bit systems. From basetsd.h: #ifdef _WIN64 typedef unsigned __int64 ULONG_PTR, *PULONG_PTR; #else /* FIXME: defined(_WIN32) */ typedef unsigned long ULONG_PTR, *PULONG_PTR; #endif But then on a 64bit system an __int64 should be the same as a long so maybe it's ok anyway. The only issue that could happen is if we try to compile Wine's dlls on a 64bit Windows system using Visual C++. Isn't a long 32bit in Visual C++? Is this a case we care about? -- Francois Gouget fgouget(a)codeweavers.com

May 15, 2007

Re: How works pGetAsyncKeyState?

by Rafał Miłecki

2007/5/14, James Liggett <jrliggett(a)cox.net>: > On Mon, 2007-05-14 at 20:12 +0200, Rafał Miłecki wrote: > > > I can not find anywhere code writing any value to "pGetAsyncKeyState" > > nor function that is executed when "pGetAsyncKeyState" is called. > What you're looking at here is a function pointer to the driver that > handles input for your windowing system (X11 in most cases.) You can > find the implementation for this function in dlls/winex11.drv/keyboard.c > in the function X11DRV_GetAsyncKeyState. That's right but I now I realize that I don't need it at all. Could someone tell me if there is some easy way to change function: > SHORT WINAPI GetAsyncKeyState(INT nKey) > { > return USER_Driver->pGetAsyncKeyState( nKey ); > } to make it use USER_Driver of __focused__ wine Window? It need to check key state in _focused_ window to be windows-compatible. -- Rafał Miłecki

May 15, 2007

Re: crypt32(5/5): Implement CryptSIPLoad

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> writes: > +static struct list providers; > +CRITICAL_SECTION providers_cs; > + > +void crypt_sip_init(void) > +{ > + InitializeCriticalSection(&providers_cs); > + list_init(&providers); > + providers_cs.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ": providers_cs"); > +} Lists and critical sections can be initialized statically, this is more efficient and avoids having to export a bunch of init functions. -- Alexandre Julliard julliard(a)winehq.org

May 15, 2007

Re: winscard stub dll

by Mounir IDRASSI

Hi, Apart from Alexandre comment, I don't see any other possible changes. So, if the first patch containing the API headers is OK, I can submit the winscard stub patch. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > Francois Gouget <fgouget(a)codeweavers.com> writes: > > >> * I would really have liked to get rid of the (unsigneg int) casts, but >> as the handle types are ULONG_PTRs it seems like it won't be possible. >> That's quite annoying. If anyone has suggestions... >> > > ULONG_PTRs are longs, they should be printed with %lx without casts. > >

May 15, 2007

Re: winscard stub dll

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > * I would really have liked to get rid of the (unsigneg int) casts, but > as the handle types are ULONG_PTRs it seems like it won't be possible. > That's quite annoying. If anyone has suggestions... ULONG_PTRs are longs, they should be printed with %lx without casts. -- Alexandre Julliard julliard(a)winehq.org

May 15, 2007

winscard stub dll

by Francois Gouget

As I was working on the winscard headers, I also did small tweaks on the winscard stub implementation. I admit it's mostly whitespace changes: * removed unneeded #includes. They should be added back when the implementation actually requires them. * use LPCBYTE like in the headers instead of 'const BYTE*' * standardize the stub traces * use 4-space indentation for functions * I would really have liked to get rid of the (unsigneg int) casts, but as the handle types are ULONG_PTRs it seems like it won't be possible. That's quite annoying. If anyone has suggestions... So I'm posting it here for review and so Mounir IDRASSI gets a chance to tweak it further and submit it so he gets the credit (since it's his work much more then mine). Makefile.in | 2 + configure | 3 + configure.ac | 1 + dlls/Makefile.in | 5 + dlls/winscard/Makefile.in | 20 +++ dlls/winscard/rsrc.rc | 33 ++++ dlls/winscard/scardcomm.c | 133 +++++++++++++++++ dlls/winscard/scarddb.c | 325 +++++++++++++++++++++++++++++++++++++++++ dlls/winscard/scardtracking.c | 104 +++++++++++++ dlls/winscard/winscard.c | 109 ++++++++++++++ dlls/winscard/winscard.spec | 66 +++++++++ 11 files changed, 801 insertions(+), 0 deletions(-) diff --git a/Makefile.in b/Makefile.in index 30e0581..eb5307f 100644 --- a/Makefile.in +++ b/Makefile.in @@ -417,6 +417,7 @@ ALL_MAKEFILES = \ dlls/winmm/Makefile \ dlls/winmm/tests/Makefile \ dlls/winnls32/Makefile \ + dlls/winscard/Makefile \ dlls/winspool.drv/Makefile \ dlls/winspool.drv/tests/Makefile \ dlls/wintab32/Makefile \ @@ -763,6 +764,7 @@ dlls/wininet/tests/Makefile: dlls/wininet/tests/Makefile.in dlls/Maketest.rules dlls/winmm/Makefile: dlls/winmm/Makefile.in dlls/Makedll.rules dlls/winmm/tests/Makefile: dlls/winmm/tests/Makefile.in dlls/Maketest.rules dlls/winnls32/Makefile: dlls/winnls32/Makefile.in dlls/Makedll.rules +dlls/winscard/Makefile: dlls/winscard/Makefile.in dlls/Makedll.rules dlls/winspool.drv/Makefile: dlls/winspool.drv/Makefile.in dlls/Makedll.rules dlls/winspool.drv/tests/Makefile: dlls/winspool.drv/tests/Makefile.in dlls/Maketest.rules dlls/wintab32/Makefile: dlls/wintab32/Makefile.in dlls/Makedll.rules diff --git a/configure b/configure index d322b0e..712a3be 100755 --- a/configure +++ b/configure @@ -20903,6 +20903,8 @@ ac_config_files="$ac_config_files dlls/winmm/tests/Makefile" ac_config_files="$ac_config_files dlls/winnls32/Makefile" +ac_config_files="$ac_config_files dlls/winscard/Makefile" + ac_config_files="$ac_config_files dlls/winspool.drv/Makefile" ac_config_files="$ac_config_files dlls/winspool.drv/tests/Makefile" @@ -21872,6 +21874,7 @@ do "dlls/winmm/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winmm/Makefile" ;; "dlls/winmm/tests/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winmm/tests/Makefile" ;; "dlls/winnls32/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winnls32/Makefile" ;; + "dlls/winscard/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winscard/Makefile" ;; "dlls/winspool.drv/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winspool.drv/Makefile" ;; "dlls/winspool.drv/tests/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winspool.drv/tests/Makefile" ;; "dlls/wintab32/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/wintab32/Makefile" ;; diff --git a/configure.ac b/configure.ac index 52323c7..6ad89eb 100644 --- a/configure.ac +++ b/configure.ac @@ -1747,6 +1747,7 @@ AC_CONFIG_FILES([dlls/wininet/tests/Makefile]) AC_CONFIG_FILES([dlls/winmm/Makefile]) AC_CONFIG_FILES([dlls/winmm/tests/Makefile]) AC_CONFIG_FILES([dlls/winnls32/Makefile]) +AC_CONFIG_FILES([dlls/winscard/Makefile]) AC_CONFIG_FILES([dlls/winspool.drv/Makefile]) AC_CONFIG_FILES([dlls/winspool.drv/tests/Makefile]) AC_CONFIG_FILES([dlls/wintab32/Makefile]) diff --git a/dlls/Makefile.in b/dlls/Makefile.in index f9707e7..31f3ef8 100644 --- a/dlls/Makefile.in +++ b/dlls/Makefile.in @@ -205,6 +205,7 @@ BASEDIRS = \ wininet \ winmm \ winnls32 \ + winscard \ winspool.drv \ wintab32 \ wintrust \ @@ -571,6 +572,7 @@ IMPORT_LIBS = \ wininet/libwininet.$(IMPLIBEXT) \ winmm/libwinmm.$(IMPLIBEXT) \ winnls32/libwinnls32.$(IMPLIBEXT) \ + winscard/libwinscard.$(IMPLIBEXT) \ winspool.drv/libwinspool.$(IMPLIBEXT) \ wintab32/libwintab32.$(IMPLIBEXT) \ wintrust/libwintrust.$(IMPLIBEXT) \ @@ -920,6 +922,9 @@ winmm/libwinmm.$(IMPLIBEXT): winmm/winmm.spec $(WINEBUILD) winnls32/libwinnls32.$(IMPLIBEXT): winnls32/winnls32.spec $(WINEBUILD) @cd winnls32 && $(MAKE) libwinnls32.$(IMPLIBEXT) + +winscard/libwinscard.$(IMPLIBEXT): winscard/winscard.spec $(WINEBUILD) + @cd winscard && $(MAKE) libwinscard.$(IMPLIBEXT) winspool.drv/libwinspool.$(IMPLIBEXT): winspool.drv/winspool.drv.spec $(WINEBUILD) @cd winspool.drv && $(MAKE) libwinspool.$(IMPLIBEXT) diff --git a/dlls/winscard/Makefile.in b/dlls/winscard/Makefile.in new file mode 100644 index 0000000..9ce7ad6 --- /dev/null +++ b/dlls/winscard/Makefile.in @@ -0,0 +1,20 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = winscard.dll +IMPORTLIB = libwinscard.$(IMPLIBEXT) +IMPORTS = kernel32 + +C_SRCS = \ + scarddb.c \ + scardcomm.c \ + scardtracking.c \ + winscard.c + +RC_SRCS = \ + rsrc.rc + +(a)MAKE_DLL_RULES@ + +(a)DEPENDENCIES@ # everything below this line is overwritten by make depend diff --git a/dlls/winscard/rsrc.rc b/dlls/winscard/rsrc.rc new file mode 100644 index 0000000..8226e9d --- /dev/null +++ b/dlls/winscard/rsrc.rc @@ -0,0 +1,33 @@ +/* + * Top level resource file for winscard.dll + * + * Copyright 2007 Mounir IDRASSI (mounir.idrassi(a)idrix.fr, for IDRIX) + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include "windef.h" +#include "winbase.h" +#include "winuser.h" +#include "winver.h" + +LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL + +#define WINE_FILEDESCRIPTION_STR "Wine Smart Card API" +#define WINE_FILENAME_STR "winscard.dll" +#define WINE_FILEVERSION 5,1,2600,2180 +#define WINE_FILEVERSION_STR "5.1.2600.2180" + +#include "wine/wine_common_ver.rc" diff --git a/dlls/winscard/scardcomm.c b/dlls/winscard/scardcomm.c new file mode 100644 index 0000000..4a5fd16 --- /dev/null +++ b/dlls/winscard/scardcomm.c @@ -0,0 +1,133 @@ +/* + * Copyright 2007 Mounir IDRASSI (mounir.idrassi(a)idrix.fr, for IDRIX) + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include "config.h" +#include "wine/port.h" + +#include <stdarg.h> +#include <stdlib.h> +#include <wchar.h> + +#include "windef.h" +#include "winbase.h" +#include "winreg.h" +#include "winscard.h" +#include "wine/debug.h" + +WINE_DEFAULT_DEBUG_CHANNEL(winscard); + + +LONG WINAPI SCardEstablishContext(DWORD dwScope, LPCVOID pvReserved1, + LPCVOID pvReserved2, + LPSCARDCONTEXT phContext) +{ + FIXME("(0x%08x %p %p %p): stub\n", dwScope, pvReserved1, pvReserved2, phContext); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + + +LONG WINAPI SCardReleaseContext(SCARDCONTEXT hContext) +{ + FIXME("(0x%08x): stub\n", (unsigned int)hContext); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardIsValidContext(SCARDCONTEXT hContext) +{ + FIXME("(0x%08x): stub\n", (unsigned int)hContext); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + + +LONG WINAPI SCardConnectA(SCARDCONTEXT hContext, LPCSTR szReader, + DWORD dwShareMode, DWORD dwPreferredProtocols, + LPSCARDHANDLE phCard, LPDWORD pdwActiveProtocol) +{ + FIXME("(0x%08x %s 0x%08x 0x%08x %p %p): stub\n", (unsigned int)hContext, debugstr_a(szReader), dwShareMode, dwPreferredProtocols, phCard, pdwActiveProtocol); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardConnectW(SCARDCONTEXT hContext, LPCWSTR szReader, + DWORD dwShareMode, DWORD dwPreferredProtocols, + LPSCARDHANDLE phCard, LPDWORD pdwActiveProtocol) +{ + FIXME("(0x%08x %s 0x%08x 0x%08x %p %p): stub\n", (unsigned int)hContext, debugstr_w(szReader), dwShareMode, dwPreferredProtocols, phCard, pdwActiveProtocol); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardReconnect(SCARDHANDLE hCard, DWORD dwShareMode, + DWORD dwPreferredProtocols, DWORD dwInitialization, + LPDWORD pdwActiveProtocol) +{ + FIXME("(0x%08x 0x%08x 0x%08x 0x%08x %p): stub\n", (unsigned int)hCard, dwShareMode, dwPreferredProtocols, dwInitialization, pdwActiveProtocol); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardDisconnect(SCARDHANDLE hCard, DWORD dwDisposition) +{ + FIXME("(0x%08x 0x%08x): stub\n", (unsigned int)hCard, dwDisposition); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardBeginTransaction(SCARDHANDLE hCard) +{ + FIXME("(0x%08x): stub\n", (unsigned int)hCard); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardEndTransaction(SCARDHANDLE hCard, DWORD dwDisposition) +{ + FIXME("(0x%08x 0x%08x): stub\n", (unsigned int)hCard, dwDisposition); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardCancelTransaction(SCARDHANDLE hCard) +{ + FIXME("(0x%08x): stub\n", (unsigned int)hCard); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardControl(SCARDHANDLE hCard, DWORD dwControlCode, + LPCVOID pbSendBuffer, DWORD cbSendLength, + LPVOID pbRecvBuffer, DWORD cbRecvLength, + LPDWORD lpBytesReturned) +{ + FIXME("(0x%08x 0x%08x %p %d %p %d %p): stub\n", (unsigned int)hCard, dwControlCode, pbSendBuffer, cbSendLength, pbRecvBuffer, cbRecvLength, lpBytesReturned); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardTransmit(SCARDHANDLE hCard, LPCSCARD_IO_REQUEST pioSendPci, + LPCBYTE pbSendBuffer, DWORD cbSendLength, + LPSCARD_IO_REQUEST pioRecvPci, LPBYTE pbRecvBuffer, + LPDWORD pcbRecvLength) +{ + FIXME("(0x%08x %p %p %d %p %p %p): stub\n", (unsigned int)hCard, pioSendPci, pbSendBuffer, cbSendLength, pioRecvPci, pbRecvBuffer, pcbRecvLength); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} diff --git a/dlls/winscard/scarddb.c b/dlls/winscard/scarddb.c new file mode 100644 index 0000000..ffe7727 --- /dev/null +++ b/dlls/winscard/scarddb.c @@ -0,0 +1,325 @@ +/* + * Copyright 2007 Mounir IDRASSI (mounir.idrassi(a)idrix.fr, for IDRIX) + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include "config.h" +#include "wine/port.h" + +#include <stdarg.h> +#include <stdlib.h> +#include <wchar.h> + +#include "windef.h" +#include "winbase.h" +#include "winreg.h" +#include "winscard.h" +#include "wine/debug.h" + +WINE_DEFAULT_DEBUG_CHANNEL(winscard); + + +/* Smart cards database functions. Almost all of them are stubs but they need + * to be present as many applications call them and are not affected if they + * return an error + */ +LONG WINAPI SCardListCardsA(SCARDCONTEXT hContext, LPCBYTE pbAtr, + LPCGUID rgquidInterfaces, + DWORD cguidInterfaceCount, LPSTR mszCards, + LPDWORD pcchCards) +{ + FIXME("(0x%08x %p %p %d %p %p): stub\n", (unsigned int)hContext, pbAtr, rgquidInterfaces, cguidInterfaceCount, mszCards, pcchCards); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardListCardsW(SCARDCONTEXT hContext, LPCBYTE pbAtr, + LPCGUID rgquidInterfaces,DWORD cguidInterfaceCount, + LPWSTR mszCards, LPDWORD pcchCards) +{ + FIXME("(0x%08x %p %p %d %p %p): stub\n", (unsigned int)hContext, pbAtr, rgquidInterfaces, cguidInterfaceCount, mszCards, pcchCards); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardListInterfacesA(SCARDCONTEXT hContext, LPCSTR szCard, + LPGUID pguidInterfaces, + LPDWORD pcguidInterfaces) +{ + FIXME("(0x%08x %s %p %p): stub\n", (unsigned int)hContext, debugstr_a(szCard), pguidInterfaces, pcguidInterfaces); + return SCARD_E_UNKNOWN_CARD; +} + +LONG WINAPI SCardListInterfacesW(SCARDCONTEXT hContext, LPCWSTR szCard, + LPGUID pguidInterfaces, + LPDWORD pcguidInterfaces) +{ + FIXME("(0x%08x %s %p %p): stub\n", (unsigned int)hContext, debugstr_w(szCard), pguidInterfaces, pcguidInterfaces); + return SCARD_E_UNKNOWN_CARD; +} + +LONG WINAPI SCardGetProviderIdA(SCARDCONTEXT hContext, LPCSTR szCard, + LPGUID pguidProviderId) +{ + FIXME("(0x%08x %s %p): stub\n", (unsigned int)hContext, debugstr_a(szCard), pguidProviderId); + if(!pguidProviderId) + return SCARD_E_INVALID_PARAMETER; + return SCARD_E_UNKNOWN_CARD; +} + +LONG WINAPI SCardGetProviderIdW(SCARDCONTEXT hContext, LPCWSTR szCard, + LPGUID pguidProviderId) +{ + FIXME("(0x%08x %s %p): stub\n", (unsigned int)hContext, debugstr_w(szCard), pguidProviderId); + if(!pguidProviderId) + return SCARD_E_INVALID_PARAMETER; + return SCARD_E_UNKNOWN_CARD; +} + +LONG WINAPI SCardGetCardTypeProviderNameA(SCARDCONTEXT hContext, + LPCSTR szCardName, + DWORD dwProviderId, LPSTR szProvider, + LPDWORD pcchProvider) +{ + FIXME("(0x%08x %s 0x%08x %p %p): stub\n", (unsigned int)hContext, debugstr_a(szCardName), dwProviderId, szProvider, pcchProvider); + return SCARD_E_UNKNOWN_CARD; +} + +LONG WINAPI SCardGetCardTypeProviderNameW(SCARDCONTEXT hContext, + LPCWSTR szCardName, + DWORD dwProviderId, + LPWSTR szProvider, + LPDWORD pcchProvider) +{ + FIXME("(0x%08x %s 0x%08x %p %p): stub\n", (unsigned int)hContext, debugstr_w(szCardName), dwProviderId, szProvider, pcchProvider); + return SCARD_E_UNKNOWN_CARD; +} + +LONG WINAPI SCardIntroduceReaderGroupA(SCARDCONTEXT hContext, + LPCSTR szGroupName) +{ + FIXME("(0x%08x %s): stub\n", (unsigned int)hContext, debugstr_a(szGroupName)); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardIntroduceReaderGroupW(SCARDCONTEXT hContext, + LPCWSTR szGroupName) +{ + FIXME("(0x%08x %s): stub\n", (unsigned int)hContext, debugstr_w(szGroupName)); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardForgetReaderGroupA(SCARDCONTEXT hContext, + LPCSTR szGroupName) +{ + FIXME("(0x%08x %s): stub\n", (unsigned int)hContext, debugstr_a(szGroupName)); + return SCARD_S_SUCCESS; +} + +LONG WINAPI SCardForgetReaderGroupW(SCARDCONTEXT hContext, + LPCWSTR szGroupName) +{ + FIXME("(0x%08x %s): stub\n", (unsigned int)hContext, debugstr_w(szGroupName)); + return SCARD_S_SUCCESS; +} + +LONG WINAPI SCardIntroduceReaderA(SCARDCONTEXT hContext, + LPCSTR szReaderName, LPCSTR szDeviceName) +{ + FIXME("(0x%08x %s %s): stub\n", (unsigned int)hContext, debugstr_a(szReaderName), debugstr_a(szDeviceName)); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardIntroduceReaderW(SCARDCONTEXT hContext, + LPCWSTR szReaderName, LPCWSTR szDeviceName) +{ + FIXME("(0x%08x %s %s): stub\n", (unsigned int)hContext, debugstr_w(szReaderName), debugstr_w(szDeviceName)); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardForgetReaderA(SCARDCONTEXT hContext, LPCSTR szReaderName) +{ + FIXME("(0x%08x %s): stub\n", (unsigned int)hContext, debugstr_a(szReaderName)); + return SCARD_S_SUCCESS; +} + +LONG WINAPI SCardForgetReaderW(SCARDCONTEXT hContext, LPCWSTR szReaderName) +{ + FIXME("(0x%08x %s): stub\n", (unsigned int)hContext, debugstr_w(szReaderName)); + return SCARD_S_SUCCESS; +} + +LONG WINAPI SCardAddReaderToGroupA(SCARDCONTEXT hContext, + LPCSTR szReaderName, LPCSTR szGroupName) +{ + FIXME("(0x%08x %s %s): stub\n", (unsigned int) hContext, debugstr_a(szReaderName), debugstr_a(szGroupName)); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardAddReaderToGroupW(SCARDCONTEXT hContext, + LPCWSTR szReaderName, LPCWSTR szGroupName) +{ + FIXME("(0x%08x %s %s): stub\n", (unsigned int)hContext, debugstr_w(szReaderName), debugstr_w(szGroupName)); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardRemoveReaderFromGroupA(SCARDCONTEXT hContext, + LPCSTR szReaderName, + LPCSTR szGroupName) +{ + FIXME("(0x%08x %s %s): stub\n", (unsigned int)hContext, debugstr_a(szReaderName), debugstr_a(szGroupName)); + return SCARD_S_SUCCESS; +} + +LONG WINAPI SCardRemoveReaderFromGroupW(SCARDCONTEXT hContext, + LPCWSTR szReaderName, + LPCWSTR szGroupName) +{ + FIXME("(0x%08x %s %s): stub\n", (unsigned int)hContext, debugstr_w(szReaderName), debugstr_w(szGroupName)); + return SCARD_S_SUCCESS; +} + +LONG WINAPI SCardIntroduceCardTypeA(SCARDCONTEXT hContext, + LPCSTR szCardName, + LPCGUID pguidPrimaryProvider, + LPCGUID rgguidInterfaces, + DWORD dwInterfaceCount, + LPCBYTE pbAtr, LPCBYTE pbAtrMask, + DWORD cbAtrLen) +{ + FIXME("(0x%08x %s %p %p %d %p %p %d): stub\n", (unsigned int)hContext, debugstr_a(szCardName), pguidPrimaryProvider, rgguidInterfaces, dwInterfaceCount, pbAtr, pbAtrMask, cbAtrLen); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardIntroduceCardTypeW(SCARDCONTEXT hContext, + LPCWSTR szCardName, + LPCGUID pguidPrimaryProvider, + LPCGUID rgguidInterfaces, + DWORD dwInterfaceCount, + LPCBYTE pbAtr, LPCBYTE pbAtrMask, + DWORD cbAtrLen) +{ + FIXME("(0x%08x %s %p %p %d %p %p %d): stub\n", (unsigned int)hContext, debugstr_w(szCardName), pguidPrimaryProvider, rgguidInterfaces, dwInterfaceCount, pbAtr, pbAtrMask, cbAtrLen); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardSetCardTypeProviderNameA(SCARDCONTEXT hContext, + LPCSTR szCardName, + DWORD dwProviderId, + LPCSTR szProvider) +{ + FIXME("(0x%08x %s 0x%08x %s): stub\n", (unsigned int)hContext, debugstr_a(szCardName), dwProviderId, debugstr_a(szProvider)); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardSetCardTypeProviderNameW(SCARDCONTEXT hContext, + LPCWSTR szCardName, + DWORD dwProviderId, + LPCWSTR szProvider) +{ + FIXME("(0x%08x %s 0x%08x %s): stub\n", (unsigned int)hContext, debugstr_w(szCardName), dwProviderId, debugstr_w(szProvider)); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardForgetCardTypeA(SCARDCONTEXT hContext, LPCSTR szCardName) +{ + FIXME("(0x%08x %s): stub\n", (unsigned int)hContext, debugstr_a(szCardName)); + return SCARD_E_UNKNOWN_CARD; +} + +LONG WINAPI SCardForgetCardTypeW(SCARDCONTEXT hContext, LPCWSTR szCardName) +{ + FIXME("(0x%08x %s): stub\n", (unsigned int)hContext, debugstr_w(szCardName)); + return SCARD_E_UNKNOWN_CARD; +} + +LONG WINAPI SCardLocateCardsA(SCARDCONTEXT hContext, LPCSTR mszCards, + LPSCARD_READERSTATEA rgReaderStates, + DWORD cReaders) +{ + FIXME("(0x%08x %s %p %d): stub\n", (unsigned int)hContext, debugstr_a(mszCards), rgReaderStates, cReaders); + return SCARD_E_UNKNOWN_CARD; +} + +LONG WINAPI SCardLocateCardsW(SCARDCONTEXT hContext, LPCWSTR mszCards, + LPSCARD_READERSTATEW rgReaderStates, + DWORD cReaders) +{ + FIXME("(0x%08x %s %p %d): stub\n", (unsigned int)hContext, debugstr_w(mszCards), rgReaderStates, cReaders); + return SCARD_E_UNKNOWN_CARD; +} + +LONG WINAPI SCardLocateCardsByATRA(SCARDCONTEXT hContext, + LPSCARD_ATRMASK rgAtrMasks, DWORD cAtrs, + LPSCARD_READERSTATEA rgReaderStates, + DWORD cReaders) +{ + FIXME("(0x%08x %p %d %p %d): stub\n", (unsigned int)hContext, rgAtrMasks, cAtrs, rgReaderStates, cReaders); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardLocateCardsByATRW(SCARDCONTEXT hContext, + LPSCARD_ATRMASK rgAtrMasks, DWORD cAtrs, + LPSCARD_READERSTATEW rgReaderStates, + DWORD cReaders) +{ + FIXME("(0x%08x %p %d %p %d): stub\n", (unsigned int)hContext, rgAtrMasks, cAtrs, rgReaderStates, cReaders); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardListReaderGroupsA(SCARDCONTEXT hContext, LPSTR mszGroups, + LPDWORD pcchGroups) +{ + FIXME("(0x%08x %p %p): stub\n", (unsigned int)hContext, mszGroups, pcchGroups); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardListReaderGroupsW(SCARDCONTEXT hContext, + LPWSTR mszGroups, LPDWORD pcchGroups) +{ + FIXME("(0x%08x %p %p): stub\n", (unsigned int)hContext, mszGroups, pcchGroups); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardListReadersA(SCARDCONTEXT hContext, LPCSTR mszGroups, + LPSTR mszReaders, LPDWORD pcchReaders) +{ + FIXME("(0x%08x %p %p %p): stub\n", (unsigned int)hContext, mszGroups, mszReaders, pcchReaders); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardListReadersW(SCARDCONTEXT hContext, LPCWSTR mszGroups, + LPWSTR mszReaders, LPDWORD pcchReaders) +{ + FIXME("(0x%08x %p %p %p): stub\n", (unsigned int)hContext, mszGroups, mszReaders, pcchReaders); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} diff --git a/dlls/winscard/scardtracking.c b/dlls/winscard/scardtracking.c new file mode 100644 index 0000000..8b109ac --- /dev/null +++ b/dlls/winscard/scardtracking.c @@ -0,0 +1,104 @@ +/* + * Copyright 2007 Mounir IDRASSI (mounir.idrassi(a)idrix.fr, for IDRIX) + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include "config.h" +#include "wine/port.h" + +#include <stdarg.h> +#include <stdlib.h> +#include <wchar.h> + +#include "windef.h" +#include "winbase.h" +#include "winreg.h" +#include "winscard.h" +#include "wine/debug.h" + +WINE_DEFAULT_DEBUG_CHANNEL(winscard); + + +LONG WINAPI SCardState(SCARDHANDLE hCard, LPDWORD pdwState, + LPDWORD pdwProtocol, LPBYTE pbAtr, LPDWORD pcbAtrLen) +{ + FIXME("(0x%08x %p %p %p %p): stub\n", (unsigned int)hCard, pdwState, pdwProtocol, pbAtr, pcbAtrLen); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardStatusA(SCARDHANDLE hCard, LPSTR mszReaderNames, + LPDWORD pcchReaderLen, LPDWORD pdwState, + LPDWORD pdwProtocol, + LPBYTE pbAtr, LPDWORD pcbAtrLen) +{ + FIXME("(0x%08x %p %p %p %p %p %p): stub\n", (unsigned int)hCard, mszReaderNames, pcchReaderLen, pdwState, pdwProtocol, pbAtr, pcbAtrLen); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardStatusW(SCARDHANDLE hCard, LPWSTR mszReaderNames, + LPDWORD pcchReaderLen, LPDWORD pdwState, + LPDWORD pdwProtocol, + LPBYTE pbAtr, LPDWORD pcbAtrLen) +{ + FIXME("(0x%08x %p %p %p %p %p %p): stub\n", (unsigned int)hCard, mszReaderNames, pcchReaderLen, pdwState, pdwProtocol, pbAtr, pcbAtrLen); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardGetStatusChangeA(SCARDCONTEXT hContext, + DWORD dwTimeout, + LPSCARD_READERSTATEA rgReaderStates, + DWORD cReaders) +{ + FIXME("(0x%08x 0x%08x %p 0x%08x): stub\n", (unsigned int)hContext, dwTimeout, rgReaderStates, cReaders); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardGetStatusChangeW(SCARDCONTEXT hContext, DWORD dwTimeout, + LPSCARD_READERSTATEW rgReaderStates, + DWORD cReaders) +{ + FIXME("(0x%08x 0x%08x %p 0x%08x): stub\n", (unsigned int)hContext, dwTimeout, rgReaderStates, cReaders); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + + +LONG WINAPI SCardCancel(SCARDCONTEXT hContext) +{ + FIXME("(0x%08x): stub\n",(unsigned int) hContext); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardGetAttrib(SCARDHANDLE hCard, DWORD dwAttrId, + LPBYTE pbAttr, LPDWORD pcbAttrLen) +{ + FIXME("(0x%08x 0x%08x %p %p): stub\n", (unsigned int)hCard, dwAttrId, pbAttr, pcbAttrLen); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardSetAttrib(SCARDHANDLE hCard, DWORD dwAttrId, + const BYTE* pbAttr, DWORD cbAttrLen) +{ + FIXME("(0x%08x 0x%08x %p 0x%08x): stub\n", (unsigned int)hCard, dwAttrId, pbAttr, cbAttrLen); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} diff --git a/dlls/winscard/winscard.c b/dlls/winscard/winscard.c new file mode 100644 index 0000000..9ed5930 --- /dev/null +++ b/dlls/winscard/winscard.c @@ -0,0 +1,109 @@ +/* + * Copyright 2007 Mounir IDRASSI (mounir.idrassi(a)idrix.fr, for IDRIX) + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include "config.h" +#include "wine/port.h" + +#include <stdarg.h> +#include <stdlib.h> +#include <wchar.h> + +#include "windef.h" +#include "winbase.h" +#include "winreg.h" +#include "winscard.h" +#include "wine/debug.h" + +WINE_DEFAULT_DEBUG_CHANNEL(winscard); + + +static HMODULE WINSCARD_hModule; + +SCARD_IO_REQUEST g_rgSCardT0Pci = { SCARD_PROTOCOL_T0, 8 }; +SCARD_IO_REQUEST g_rgSCardT1Pci = { SCARD_PROTOCOL_T1, 8 }; +SCARD_IO_REQUEST g_rgSCardRawPci = { SCARD_PROTOCOL_RAW, 8 }; + +SCARD_IO_REQUEST* SCARD_PCI_T0 = NULL; +SCARD_IO_REQUEST* SCARD_PCI_T1 = NULL; +SCARD_IO_REQUEST* SCARD_PCI_RAW = NULL; + + +BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) +{ + TRACE("%p,%x,%p\n", hinstDLL, fdwReason, lpvReserved); + + switch (fdwReason) { + case DLL_PROCESS_ATTACH: + DisableThreadLibraryCalls(hinstDLL); + WINSCARD_hModule = hinstDLL; + /* initialize protocol requests pointers */ + SCARD_PCI_T0 = &g_rgSCardT0Pci; + SCARD_PCI_T1 = &g_rgSCardT1Pci; + SCARD_PCI_RAW = &g_rgSCardRawPci; + break; + case DLL_PROCESS_DETACH: + break; + } + + return TRUE; +} + + +/* + * event functions + */ + +HANDLE WINAPI SCardAccessNewReaderEvent() +{ + FIXME("stub\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return NULL; +} + +long WINAPI SCardReleaseAllEvents() +{ + FIXME("stub\n"); + return SCARD_S_SUCCESS; +} + +long WINAPI SCardReleaseNewReaderEvent(HANDLE hNewReaderEventHandle) +{ + FIXME("stub\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_S_SUCCESS; +} + +HANDLE WINAPI SCardAccessStartedEvent() +{ + FIXME("stub\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return NULL; +} + +void WINAPI SCardReleaseStartedEvent(void) +{ + FIXME("stub\n"); +} + + +LONG WINAPI SCardFreeMemory( SCARDCONTEXT hContext,LPCVOID pvMem) +{ + FIXME("(0x%08X %p): stub\n", (unsigned int)hContext, pvMem); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} diff --git a/dlls/winscard/winscard.spec b/dlls/winscard/winscard.spec new file mode 100644 index 0000000..c2bbe55 --- /dev/null +++ b/dlls/winscard/winscard.spec @@ -0,0 +1,66 @@ +@ stub ClassInstall32 +@ stdcall SCardAccessNewReaderEvent() +@ stdcall SCardAccessStartedEvent() +@ stdcall SCardAddReaderToGroupA(long str str) +@ stdcall SCardAddReaderToGroupW(long wstr wstr) +@ stdcall SCardBeginTransaction(long) +@ stdcall SCardCancel(long) +@ stdcall SCardConnectA(long str long long ptr ptr) +@ stdcall SCardConnectW(long wstr long long ptr ptr) +@ stdcall SCardControl(long long ptr long ptr long ptr) +@ stdcall SCardDisconnect(long long) +@ stdcall SCardEndTransaction(long long) +@ stdcall SCardEstablishContext(long ptr ptr ptr) +@ stdcall SCardForgetCardTypeA(long str) +@ stdcall SCardForgetCardTypeW(long wstr) +@ stdcall SCardForgetReaderA(long str) +@ stdcall SCardForgetReaderW(long wstr) +@ stdcall SCardForgetReaderGroupA(long str) +@ stdcall SCardForgetReaderGroupW(long wstr) +@ stdcall SCardFreeMemory(long ptr) +@ stdcall SCardGetAttrib(long long ptr ptr) +@ stdcall SCardGetCardTypeProviderNameA(long str long str ptr) +@ stdcall SCardGetCardTypeProviderNameW(long wstr long wstr ptr) +@ stdcall SCardGetProviderIdA(long str ptr) +@ stdcall SCardGetProviderIdW(long wstr ptr) +@ stdcall SCardGetStatusChangeA(long long ptr long) +@ stdcall SCardGetStatusChangeW(long long ptr long) +@ stdcall SCardIntroduceCardTypeA(long str ptr ptr long ptr ptr long) +@ stdcall SCardIntroduceCardTypeW(long wstr ptr ptr long ptr ptr long) +@ stdcall SCardIntroduceReaderA(long str str) +@ stdcall SCardIntroduceReaderW(long wstr wstr) +@ stdcall SCardIntroduceReaderGroupA(long str) +@ stdcall SCardIntroduceReaderGroupW(long wstr) +@ stdcall SCardIsValidContext(long) +@ stdcall SCardListCardsA(long ptr ptr long str ptr) +@ stdcall SCardListCardsW(long ptr ptr long wstr ptr) +@ stdcall SCardListInterfacesA(long str ptr ptr) +@ stdcall SCardListInterfacesW(long wstr ptr ptr) +@ stdcall SCardListReadersA(long str str ptr) +@ stdcall SCardListReadersW(long wstr wstr ptr) +@ stdcall SCardListReaderGroupsA(long str ptr) +@ stdcall SCardListReaderGroupsW(long wstr ptr) +@ stdcall SCardLocateCardsA(long str ptr long) +@ stdcall SCardLocateCardsW(long wstr ptr long) +@ stdcall SCardLocateCardsByATRA(long ptr long ptr long) +@ stdcall SCardLocateCardsByATRW(long ptr long ptr long) +@ stdcall SCardReconnect(long long long long ptr) +@ stdcall SCardReleaseAllEvents() +@ stdcall SCardReleaseContext(long) +@ stdcall SCardReleaseNewReaderEvent() +@ stdcall SCardReleaseStartedEvent() +@ stdcall SCardRemoveReaderFromGroupA(long str str) +@ stdcall SCardRemoveReaderFromGroupW(long wstr wstr) +@ stdcall SCardSetAttrib(long long ptr long) +@ stdcall SCardSetCardTypeProviderNameA(long str long str) +@ stdcall SCardSetCardTypeProviderNameW(long wstr long wstr) +@ stdcall SCardState(long ptr ptr ptr ptr) +@ stdcall SCardStatusA(long str ptr ptr ptr ptr ptr) +@ stdcall SCardStatusW(long wstr ptr ptr ptr ptr ptr) +@ stdcall SCardTransmit(long ptr ptr long ptr ptr ptr) +@ extern g_rgSCardRawPci +@ extern g_rgSCardT0Pci +@ extern g_rgSCardT1Pci +@ extern SCARD_PCI_RAW +@ extern SCARD_PCI_T0 +@ extern SCARD_PCI_T1 -- 1.4.4.4

May 15, 2007

Re: mentoring

by Stefan Dösinger

Am Dienstag 15 Mai 2007 02:33 schrieb Ivan Gyurdiev: > > What Stefan says about discussing patches > > is true--it helps if there's not a lot of debate around a patch. > > This quote should go down in the history of open source :) > I hope the word you're looking for is "controversy". Yes, "controvery" better describes what I wanted to say. Hope you can forgive a non-native speaker(german native) picking a slightly inappropiate word :-)

May 15, 2007

Re: mentoring

by Chris Howe

Can I just chime in here as a newbie Wine developer working on his first patch and say that I find this kind of discussion invaluable? I've lurked on wine-devel for a while and tried to gauge the answers to these questions before, and personally bothered some of the devs with a few questions that are all probably FAQ but weren't mentioned anywhere online. I was wondering if these are the kinds of things that would be useful to find their way onto the Wiki as a guide to new contributors that goes beyond the (already well covered) technical aspects?

May 15, 2007

Re: CMD.EXE patchset 1->6

by Robert Shearman

Ann & Jason Edmeades wrote: > Apologies if this set arrives multiple times - I sent it all on Friday, and > the mailing list only shows 1,2 and 4. I sent then again tonight separately, > and immediately 3 went missing... > > FYI I had this problem before the last hardware upgrade on winehq, and it > appeared fixed since then. I'll start copying a gmail account in future to > confirm what I am seeing, but last time some emails got delayed about a > month in transit and eventually appeared, but ONLY when winehq was involved, > gmail, hotmail, my own email addr etc all got immediate copies... I believe what is happening is that the WineHQ mail server only accepts one SMTP connection at a time. This will probably reject half the messages sent by your mail server. Then they will get resent after a short period of time, but in batches so more messages will get rejected and then resent after a longer period of time, and so on until all the messages have been sent. What probably sets your mail server apart from the gmail servers, for example, is that gmail probably sends out each message individually, rather than batching it with other messages bound for WineHQ. -- Rob Shearman

May 15, 2007

Re: [tools] add winecfg to XDG menus

by Damjan Jovanovic

On 5/15/07, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On Tue, May 15, 2007 at 07:36:38AM +0200, Damjan Jovanovic wrote: > > Changelog: > > * When installing wine, add an entry for winecfg to the XDG menus > > > > Damjan Jovanovic > > > diff -Nur a/tools/Makefile.in b/tools/Makefile.in > > --- a/tools/Makefile.in 2007-05-03 08:46:44.000000000 +0200 > > +++ b/tools/Makefile.in 2007-05-14 21:59:17.646137077 +0200 > > @@ -82,7 +82,11 @@ > > install install-lib:: wineprefixcreate $(INSTALLDIRS) > > $(INSTALL_SCRIPT) wineprefixcreate $(DESTDIR)$(bindir)/wineprefixcreate > > $(INSTALL_DATA) $(SRCDIR)/wine.inf $(DESTDIR)$(datadir)/wine/wine.inf > > + mkdir -p /etc/xdg/menus &> /dev/null || true > > + mkdir -p ~/.config/menus/applications-merged > > + if ! $(INSTALL_DATA) $(SRCDIR)/wine.menu /etc/xdg/menus &> /dev/null; then $(INSTALL_DATA) $(SRCDIR)/wine.menu ~/.config/menus/applications-merged; fi > > Please do not use ~. You are not supposed to put stuff into any > kind of $HOMEs. What about menus, they have to either go into /etc/xdg/menus or ~/.config/menus/applications-merged? > Please use $(DESTDIR) for global paths. > > Ciao, Marcus > > >

May 15, 2007

Re: [tools] add winecfg to XDG menus

by Marcus Meissner

On Tue, May 15, 2007 at 07:36:38AM +0200, Damjan Jovanovic wrote: > Changelog: > * When installing wine, add an entry for winecfg to the XDG menus > > Damjan Jovanovic > diff -Nur a/tools/Makefile.in b/tools/Makefile.in > --- a/tools/Makefile.in 2007-05-03 08:46:44.000000000 +0200 > +++ b/tools/Makefile.in 2007-05-14 21:59:17.646137077 +0200 > @@ -82,7 +82,11 @@ > install install-lib:: wineprefixcreate $(INSTALLDIRS) > $(INSTALL_SCRIPT) wineprefixcreate $(DESTDIR)$(bindir)/wineprefixcreate > $(INSTALL_DATA) $(SRCDIR)/wine.inf $(DESTDIR)$(datadir)/wine/wine.inf > + mkdir -p /etc/xdg/menus &> /dev/null || true > + mkdir -p ~/.config/menus/applications-merged > + if ! $(INSTALL_DATA) $(SRCDIR)/wine.menu /etc/xdg/menus &> /dev/null; then $(INSTALL_DATA) $(SRCDIR)/wine.menu ~/.config/menus/applications-merged; fi Please do not use ~. You are not supposed to put stuff into any kind of $HOMEs. Please use $(DESTDIR) for global paths. Ciao, Marcus

May 15, 2007

Re: Install fail on 64bit syst Q

by Dmitry Timoshkov

<wkpickett0154(a)comcast.net> wrote: > Running configure... > > configure: creating cache config.cache > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking whether make sets $(MAKE)... yes > checking for gcc... gcc -m32 > checking for C compiler default output file name... > configure: error: C compiler cannot create executables > See `config.log' for more details. > > Configure failed, aborting install. Check out these instructions: http://wiki.winehq.org/WineOn64bit -- Dmitry.

May 14, 2007

Re: mentoring

by James Liggett

On Mon, 2007-05-14 at 20:33 -0400, Ivan Gyurdiev wrote: > > What Stefan says about discussing patches > > is true--it helps if there's not a lot of debate around a patch. > > > This quote should go down in the history of open source :) > I hope the word you're looking for is "controversy". Yeah, "controversy" would work, But, debate and controversy are essentially the same thing, aren't they? :) Put simply, if no one can agree on what the right way is, we're not going to go anywhere, are we? That's why we have a maintainer like Alexandre--to help lay down the law and keep the project on track. To clarify, what I really meant was that maybe Tom should wait a bit until said controversy is resolved before messing with this stuff so he doesn't waste his time.

May 14, 2007

Re: Install fail on 64bit syst Q

by Evil Jay

Are you trying to build with (K)ubuntu Feisty (7.04)? I was able to build the 64-bit version fine on Kubuntu Gutsy Gibbon (7.10) after I installed all the prerequisite libraries. -J wkpickett0154(a)comcast.net wrote: > Hello, > I am aware that wine currently installs on 32 bit only according to numerous blogentries. Here is my congif.log on this attempt to better assist in a X86_64 generic compile. > > I suppose, on my ignorance- that this compile needs to be put in a different location to be called for? I am new to Linux/Ubuntu and programming language-speak, so any help here, non-tech type would be a help. > > William Pickett > Albuquerque NM > > WINE Installer v0.75 > > Running configure... > > configure: creating cache config.cache > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking whether make sets $(MAKE)... yes > checking for gcc... gcc -m32 > checking for C compiler default output file name... > configure: error: C compiler cannot create executables > See `config.log' for more details. > >

May 14, 2007

Re: Install fail on 64bit syst Q

by richardvoigt＠gmail.com

> configure:2404: checking for C compiler default output file name > configure:2431: gcc -m32 conftest.c >&5 > /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when searching for -lc > /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc > /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc > /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc > /usr/bin/ld: cannot find -lc > collect2: ld returned 1 exit status This is your problem... you don't have a 32-bit version of glibc, so although your compiler can compile 32-bit programs such as wine just fine, the library functions are missing. As noted in a previous response, your distro can give you instructions for installing a 32-bit glibc, either a pre-built binary or compiling it yourself.

May 14, 2007

Re: mentoring

by Ivan Gyurdiev

> What Stefan says about discussing patches > is true--it helps if there's not a lot of debate around a patch. > This quote should go down in the history of open source :) I hope the word you're looking for is "controversy".

May 14, 2007

Re: Install fail on 64bit syst Q

by Ben Hodgetts (Enverex)

wkpickett0154(a)comcast.net wrote: > Hello, > I am aware that wine currently installs on 32 bit only according to numerous blogentries. Here is my congif.log on this attempt to better assist in a X86_64 generic compile. > > I suppose, on my ignorance- that this compile needs to be put in a different location to be called for? I am new to Linux/Ubuntu and programming language-speak, so any help here, non-tech type would be a help. > > William Pickett > Albuquerque NM > > WINE Installer v0.75 > > Running configure... > > configure: creating cache config.cache > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking whether make sets $(MAKE)... yes > checking for gcc... gcc -m32 > checking for C compiler default output file name... > configure: error: C compiler cannot create executables > See `config.log' for more details. > > Configure failed, aborting install. > > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by Wine configure 0.9.37, which was > generated by GNU Autoconf 2.61. Invocation command line was > > $ ./configure -C --prefix=/usr/local > > --- cropped > Wine compiles fine on 64bit machines, you just don't have everything needed to compile software installed on your machine. This is a Wine developer mailing list and you should not be posting this here. Please direct it to your Linux distro forums or IRC. Ben H

May 14, 2007

Install fail on 64bit syst Q

by wkpickett0154＠comcast.net

Hello, I am aware that wine currently installs on 32 bit only according to numerous blogentries. Here is my congif.log on this attempt to better assist in a X86_64 generic compile. I suppose, on my ignorance- that this compile needs to be put in a different location to be called for? I am new to Linux/Ubuntu and programming language-speak, so any help here, non-tech type would be a help. William Pickett Albuquerque NM WINE Installer v0.75 Running configure... configure: creating cache config.cache checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking whether make sets $(MAKE)... yes checking for gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. Configure failed, aborting install. This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Wine configure 0.9.37, which was generated by GNU Autoconf 2.61. Invocation command line was $ ./configure -C --prefix=/usr/local ## --------- ## ## Platform. ## ## --------- ## hostname = c21william-desktop uname -m = x86_64 uname -r = 2.6.20-15-generic uname -s = Linux uname -v = #2 SMP Sun Apr 15 06:17:24 UTC 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/bin/X11 PATH: /usr/games ## ----------- ## ## Core tests. ## ## ----------- ## configure:1737: creating cache config.cache configure:1888: checking build system type configure:1906: result: x86_64-unknown-linux-gnu configure:1928: checking host system type configure:1943: result: x86_64-unknown-linux-gnu configure:2008: checking whether make sets $(MAKE) configure:2029: result: yes configure:2086: checking for gcc configure:2113: result: gcc -m32 configure:2351: checking for C compiler version configure:2358: gcc -m32 --version >&5 gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2361: $? = 0 configure:2368: gcc -m32 -v >&5 Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) configure:2371: $? = 0 configure:2378: gcc -m32 -V >&5 gcc: '-V' must come at the start of the command line configure:2381: $? = 1 configure:2404: checking for C compiler default output file name configure:2431: gcc -m32 conftest.c >&5 /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc /usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status configure:2434: $? = 1 configure:2472: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "0.9.37" | #define PACKAGE_STRING "Wine 0.9.37" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2479: error: C compiler cannot create executables See `config.log' for more details. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=x86_64-unknown-linux-gnu ac_cv_env_CCC_set= ac_cv_env_CCC_value= ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_XMKMF_set= ac_cv_env_XMKMF_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=x86_64-unknown-linux-gnu ac_cv_prog_ac_ct_CC='gcc -m32' ac_cv_prog_make_make_set=yes ## ----------------- ## ## Output variables. ## ## ----------------- ## ALSALIBS='' AR='' AS='as --32' AUDIOIOLIBS='' BISON='' BUILTINFLAG='' CARBONLIB='' CC='gcc -m32' CFLAGS='' COREAUDIO='' COREFOUNDATIONLIB='' CPP='' CPPBIN='' CPPFLAGS='' CROSSCC='' CROSSTEST='' CROSSWINDRES='' CRTLIBS='' CXX='' CXXFLAGS='' DEFS='' DEPENDENCIES='' DISKARBITRATIONLIB='' DLLEXT='' DLLFLAGS='' DLLTOOL='' DLLWRAP='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' ESDCONFIG='' ESDINCL='' ESDLIBS='' EXEEXT='' EXTRACFLAGS='' EXTRA_BINARIES='' FLEX='' FONTFORGE='' FONTSSUBDIRS='' FREETYPEINCL='' FREETYPELIBS='' GLU32FILES='' GPHOTO2INCL='' GPHOTO2LIBS='' GREP='' HALINCL='' ICULIBS='' IMPLIBEXT='' INSTALL_DATA='' INSTALL_PROGRAM='' INSTALL_SCRIPT='' IOKITLIB='' LCMSLIBS='' LD='ld -m elf_i386' LDAPLIBS='' LDCONFIG='' LDD='' LDDLLFLAGS='' LDEXECFLAGS='' LDFLAGS='' LDPATH='' LDSHARED='' LIBDL='' LIBEXT='' LIBOBJS='' LIBPOLL='' LIBPTHREAD='' LIBS='' LIBWINE_LDFLAGS='' LINT='' LINTFLAGS='' LN='' LN_S='' LTLIBOBJS='' MAIN_BINARY='' MINGWAR='' NASLIBS='' OBJEXT='' OPENGLFILES='' OPENGL_LIBS='' PACKAGE_BUGREPORT='wine-devel(a)winehq.org' PACKAGE_NAME='Wine' PACKAGE_STRING='Wine 0.9.37' PACKAGE_TARNAME='wine' PACKAGE_VERSION='0.9.37' PATH_SEPARATOR=':' PKG_CONFIG='' PRELINK='' QUARTZFILES='' RANLIB='' RESOLVLIBS='' SANEINCL='' SET_MAKE='' SHELL='/bin/bash' SOCKETLIBS='' STRIP='' TOOLSDIR='' WIN16_FILES='$(WIN16_FILES)' WIN16_INSTALL='$(WIN16_INSTALL)' WINDRES='' XFILES='' XLIB='' XMKMF='' XML2INCL='' XML2LIBS='' XSLTINCL='' XSLTLIBS='' X_CFLAGS='' X_EXTRA_LIBS='' X_LIBS='' X_PRE_LIBS='' ac_ct_AS='' ac_ct_CC='gcc -m32' ac_ct_CXX='' bindir='${exec_prefix}/bin' build='x86_64-unknown-linux-gnu' build_alias='' build_cpu='x86_64' build_os='linux-gnu' build_vendor='unknown' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='NONE' ft_devel2='' ft_devel='' gphoto2_devel='' gphoto2port_devel='' host='x86_64-unknown-linux-gnu' host_alias='' host_cpu='i386' host_os='linux-gnu' host_vendor='unknown' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/usr/local' program_transform_name='s,x,x,' psdir='${docdir}' sane_devel='' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ------------------- ## ## File substitutions. ## ## ------------------- ## MAKE_DLL_RULES='' MAKE_IMPLIB_RULES='' MAKE_PROG_RULES='' MAKE_RULES='' MAKE_TEST_RULES='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_NAME "Wine" #define PACKAGE_TARNAME "wine" #define PACKAGE_VERSION "0.9.37" #define PACKAGE_STRING "Wine 0.9.37" #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" configure: exit 77

May 14, 2007

Re: mentoring

by James Liggett

On Mon, 2007-05-14 at 13:56 -0500, Tom Spear wrote: Hey Tom, > My last question is this: What is an acceptable amount of time I > should wait before asking AJ what is wrong with a patch? I see that > patches get submitted and then the next day they are committed > oftentimes. However I would like I am pressuring him if I submit a > patch, it didnt get committed the next day, and then I shortly after > ask him what was wrong. So, should I wait until day 2 or so? > Unfortunately my company firewall blocks all of the IRC ports, so I > can't get onto freenode from work, and by the time I get home, most > times #winehackers (well #winehq anyways) is dead. I'll check in > winehackers next time.. > > Thank you very much for putting my fears to rest. Now for the arduous > task of starting over heheh. If it's a big patch, it might take AJ 3-4 days to review it; with some of my previous stuff, I waited a week just to be sure. That being said, I second Stefan's advice. I've been where you are with the XEmbed systray stuff, and I know it's tough, but it's doable--don't give up ;-) Personally I think IRC is hands-down the best way to get advice from Alexandre. I would have never gotten the systray stuff done if I had never found him there. Also, it may be a good idea to let this stuff cool down a bit. This may seem like a long time, but give it maybe three months or more before you start messing with this again. What Stefan says about discussing patches is true--it helps if there's not a lot of debate around a patch. If you're still having issues with some technical aspects of the patch, try contacting the author of the original code. It's a bit of a long shot if said developer isn't around anymore, but you might get lucky and he may be able to give some guidance. I, for instance, was able to get some help from the original author of the XEmebed systray patch to help me get it in. I'm really rooting for you. If I can do it, I know you can. Just be patient and you'll pull through. :-) Hope this helps, James Liggett

May 14, 2007

Re: How works pGetAsyncKeyState?

by James Liggett

On Mon, 2007-05-14 at 20:12 +0200, Rafał Miłecki wrote: > I can not find anywhere code writing any value to "pGetAsyncKeyState" > nor function that is executed when "pGetAsyncKeyState" is called. What you're looking at here is a function pointer to the driver that handles input for your windowing system (X11 in most cases.) You can find the implementation for this function in dlls/winex11.drv/keyboard.c in the function X11DRV_GetAsyncKeyState. HTH

May 14, 2007

Re: mentoring

by Stefan Dösinger

> My last question is this: What is an acceptable amount of time I > should wait before asking AJ what is wrong with a patch? I see that > patches get submitted and then the next day they are committed > oftentimes. However I would like I am pressuring him if I submit a > patch, it didnt get committed the next day, and then I shortly after > ask him what was wrong. So, should I wait until day 2 or so? > Unfortunately my company firewall blocks all of the IRC ports, so I > can't get onto freenode from work, and by the time I get home, most > times #winehackers (well #winehq anyways) is dead. I'll check in > winehackers next time.. You have noticed it correctly. Usually aj commits at 2 pm central european time and 8 pm. Patches that are on wine-patches 6 hours before get in usually, except if there are just too many aj can handle in one go. AJ doesn't commit on weekends. I think if the patch isn't committed withhin 2 commit waves after you sent it its ok to ask. (Ok, I personally get impatient someimtes and ask earlier). As for channels beeing dead, quite often there is no talk if there is nothing to discuss, just ping people if you want to talk to them. Aj is usually around between 10 am central european time and 10-11 pm cet, but I'm not sure in the morning as I'm quite often not in then.

May 14, 2007

Re: mentoring

by Tom Spear

On 5/14/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi Tom! > I am afraid you have come accross an unmaintained part of wine. There is maybe > nobody who can competently help you. Nobody minds helping you, but nobody can > help you. > > What happens then is that you write a mail and get no answers. You get > frustrated(not your fault), write a mail in which you complain nobody has > answered. 3 persons who do no know the part of wine you're modifying reply 3 > different answers. Discussions start, and then AJ stops applying patches > until the discussions have come to a conclusion. Ok, thank you very much. That was exactly what I needed to hear. > Thats just what I think has happened, but I don't know the uninstaller eiter. > So count this as a 4th answer to "why does nobody answer me" :-) It wasnt so much a question of why does nobody answer me.. I have been getting responses, it's just that I was not getting anywhere with the responses I was getting. I have all of the information I need I think to be able to finally get this handled now.. > As for finding out what aj disliked about your patches my experience is that > it is best to ask him on irc(#winehackers on freenode). But I also know that > aj stops looking at patches if there is way too much dispute about them. In > this case you should send single patches to wine-patches starting that you > want to start the process over. Of course the patches should have the > suggestions implemented that were made before, or if not a good reason why > you have chosen to do otherwise(Not all suggestions are good). My last question is this: What is an acceptable amount of time I should wait before asking AJ what is wrong with a patch? I see that patches get submitted and then the next day they are committed oftentimes. However I would like I am pressuring him if I submit a patch, it didnt get committed the next day, and then I shortly after ask him what was wrong. So, should I wait until day 2 or so? Unfortunately my company firewall blocks all of the IRC ports, so I can't get onto freenode from work, and by the time I get home, most times #winehackers (well #winehq anyways) is dead. I'll check in winehackers next time.. Thank you very much for putting my fears to rest. Now for the arduous task of starting over heheh. -- Thanks Tom

May 14, 2007

Re: OpenAL32 dll thunk test

by Alexandre Julliard

Chris Robinson <chris.kcat(a)gmail.com> writes: > After the previous attempt by Nick Burns was more or less abandoned, I decided > to try making an acceptable version myself. This is the current result. > > I used the original version Nick had and got rid a lot of the macro abuse. It > still uses macros to declare/define and load the functions, but it isn't > nearly as bad as it was. I know AJ isn't very thrilled with macro use, but I > believe the current method is a nice balance between flexibility and clarity. Sorry, but it's still very bad. If you don't want to type all the functions by hand, you should write a perl script to generate them like OpenGL does. Either way the end result should look as far as possible like normal C code. -- Alexandre Julliard julliard(a)winehq.org

May 14, 2007

How works pGetAsyncKeyState?

by Rafał Miłecki

Hello, It's my first time I look into source of Wine. I found a bug near dlls/user32/input.c. You can find here this code: SHORT WINAPI GetAsyncKeyState(INT nKey) { return USER_Driver->pGetAsyncKeyState( nKey ); } The problem is that this function don't return right value in every case. Could someone explain me how it works, please? I can not find anywhere code writing any value to "pGetAsyncKeyState" nor function that is executed when "pGetAsyncKeyState" is called. -- Rafał Miłecki

May 14, 2007

How works pGetAsyncKeyState?

by Rafał Miłecki

Hello, It's my first time I look into source of Wine. I found a bug near dlls/user32/input.c. You can find here this code: SHORT WINAPI GetAsyncKeyState(INT nKey) { return USER_Driver->pGetAsyncKeyState( nKey ); } The problem is that this function don't return right value in every case. Could someone explain me how it works, please? I can not find anywhere code writing any value to "pGetAsyncKeyState" nor function that is executed when "pGetAsyncKeyState" is called. -- Rafał Miłecki

May 14, 2007

Re: mentoring

by Stefan Dösinger

Hi Tom! I am afraid you have come accross an unmaintained part of wine. There is maybe nobody who can competently help you. Nobody minds helping you, but nobody can help you. What happens then is that you write a mail and get no answers. You get frustrated(not your fault), write a mail in which you complain nobody has answered. 3 persons who do no know the part of wine you're modifying reply 3 different answers. Discussions start, and then AJ stops applying patches until the discussions have come to a conclusion. Thats just what I think has happened, but I don't know the uninstaller eiter. So count this as a 4th answer to "why does nobody answer me" :-) As for finding out what aj disliked about your patches my experience is that it is best to ask him on irc(#winehackers on freenode). But I also know that aj stops looking at patches if there is way too much dispute about them. In this case you should send single patches to wine-patches starting that you want to start the process over. Of course the patches should have the suggestions implemented that were made before, or if not a good reason why you have chosen to do otherwise(Not all suggestions are good).

May 14, 2007

Re: [PATCH 2/8] msi/tests: automation: Add test for Installer::InstallProduct.

by Misha Koshelev

On Mon, 2007-05-14 at 10:41 -0600, James Hawkins wrote: > On 5/14/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > > --- > > dlls/msi/tests/automation.c | 307 ++++++++++++++++++++++++++++++++++++++++++- > > 1 files changed, 300 insertions(+), 7 deletions(-) > > > > + /* Installer::ProductState for our product code, which has been > installed */ > + hr = Installer_ProductState(szProductCode, &iValue); > + ok(SUCCEEDED(hr), "Installer_ProductState failed, hresult 0x%08x\n", hr); > + if (SUCCEEDED(hr)) > + todo_wine ok(iValue == INSTALLSTATE_DEFAULT, > "Installer_ProductState returned %d, expected %d\n", iValue, > INSTALLSTATE_DEFAULT); > > If you're assuming that hr SUCCEEDED (which you are by putting that > check in ok), then you shouldn't condition the next ok on > SUCCEEDED(hr). > Good point. Misha

May 14, 2007

mentoring

by Tom Spear

Hi all, just wanted to know if anyone would _mind_ helping me with my (small) todo list. I know I've been somewhat of an annoyance lately, and for that I sincerely apologize. I'd really like to get the wine uninstaller program up to speed with the patch I have been working on, but it is not going as I had hoped. One person offered to review my patches, but I am admittedly impatient sometimes (I haven't been able to get a response from him since Thursday, and I had hoped for one by Friday night), and all in all, I just dont like having something so small take so long. I am making changes to code I didn't intend to change, which I don't mind doing, but then when I make the change, I get told to do it 3 different ways, and none of the ways I submit gets committed, even after being told that it looks ready to go in. I'd like someone who is really in touch with what Alexandre is looking for to help me. I only have 4 patches, all less than 50 lines each to get this thing in, and I will be done submitting patches for a while, until I learn more about the code (maybe months or even years).. I will take whatever advice is given me (unless it is to not bother with the patch), and really appreciate the help. If you dont mind helping me, please post a note on my bug about the patch http://bugs.winehq.org/show_bug.cgi?id=8364 -- Thanks Tom

May 14, 2007

Re: [PATCH 2/8] msi/tests: automation: Add test for Installer::InstallProduct.

by James Hawkins

On 5/14/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > --- > dlls/msi/tests/automation.c | 307 ++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 300 insertions(+), 7 deletions(-) > + /* Installer::ProductState for our product code, which has been installed */ + hr = Installer_ProductState(szProductCode, &iValue); + ok(SUCCEEDED(hr), "Installer_ProductState failed, hresult 0x%08x\n", hr); + if (SUCCEEDED(hr)) + todo_wine ok(iValue == INSTALLSTATE_DEFAULT, "Installer_ProductState returned %d, expected %d\n", iValue, INSTALLSTATE_DEFAULT); If you're assuming that hr SUCCEEDED (which you are by putting that check in ok), then you shouldn't condition the next ok on SUCCEEDED(hr). -- James Hawkins

May 14, 2007

Re: OpenAL32 dll thunk test

by Steven Edwards

On 5/14/07, Chris Robinson <chris.kcat(a)gmail.com> wrote: > a) Skip building the DLL if OpenAL headers aren't found on the system > durring ./configure (any autotools experts want to help?) > b) Properly handle the autotools stuff (any autotools experts want to help?) It seems like it would not be to hard to just copy the conditional autotools magic we use for OpenGL in configure and dllls/Makefile.in. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 14, 2007