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

Re: kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS & incorrectGetLastError() codes fix

by Dmitry Timoshkov

"Andrew O. Shadoura" <bugzilla(a)tut.by> wrote: > This patch implements MB_USEGLYPHCHARS flag in MultiByteToWideChar function > and fixes incorrect error codes (in case of CP_SYMBOL charset non-zero dwFlags > should give ERROR_INVALID_FLAGS, not ERROR_INVALID_PARAMETER, almost the same > with CP_UTF8, but "dwFlags must be set to either 0 or MB_ERR_INVALID_CHARS" > according to MSDN: http://msdn2.microsoft.com/en-us/library/ms776413.aspx > Also, test case is added. Please follow the existing code style of the files you're changing (indentation, braces, spaces), don't mix tabs and spaces. > + for (i=0; i!=length; i++) { > + if (str[i]<0x20) str[i]=glyph_xlat[str[i]]; > + } This is rather an unusual style of breaking out of the loop, 'i < length' is less confusing IMO. -- Dmitry.

May 4, 2007

re: Implement MsiBreak Feature - Bug 8243

by Dan Kegel

> Do we really need to write out unix pid? > AFAIK Winedbg can attach to windows process IDs just fine. Hrmph. The author did say in http://bugs.winehq.org/show_bug.cgi?id=8243 that he needed Windows PIDs, didn't say he needed Unix pids. so maybe you're right. Let's ask him. Hey, Anastasius, do you really need the unix pid? - Dan

May 3, 2007

USB device support in wine

by Jon Burgess

Hi, I have found some talk of implementing USB device support in wine in this list some time ago (2005), but as far as I know, nothing ever came of it. I would perhaps be interested in getting this going again, as I have an application (Serato Scratch Live: http://www.rane.com/scratch.html) for which the software appears to run ok under wine (not that I am able to test much of its functionality on the other hand), but is utterly useless without support for its associated USB hardware device. Any ideas, or anyone else who would be interested in helping me? Regards, Jono

May 3, 2007

Re: dinput : crash of Pro Evolution Soccer 3 with a joystick

by Vitaliy Margolen

What's the bug number for this? Did you debugged the crash to the particular information Wine returns/doesn't return? Sébastien GRIPON wrote: > Hi, > > I try to play to Pro Evolution Soccer 3 on my Ubuntu Fesity Fawn and > it's not far to be possible. Every wine release brings a lots of wined3d > improvements and pes3 is almost playable. Many textures are missing, but > it's on a good way. Congratulations ! > > However, I have a problem with my joystick. I have a Microsoft > Sidewinder and a Thrustmaster and when any of them is plugged on an USB > port, the exe pes3.exe or the PES configuration tool setting.exe crash. > This crash doesn't occur when joysticks are not pluggued. I tried to > debug this crash, but it is a very hard work. I think dinput is involved > but I can't be sure. > > If you're interesting in this game, this is the crash dump. > > Thank you, > > Seb. > > $ wine setting.exe > fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE > wine: Unhandled page fault on read access to 0x00000000 at address (nil) > (thread 0009), starting debugger... > Unhandled exception: page fault on read access to 0x00000000 in 32-bit > code (0x00000000). > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b > EIP:00000000 ESP:0033f518 EBP:0058b2a8 EFLAGS:00210246( - 00 > -RIZP1) > EAX:00182c18 EBX:00000000 ECX:7da5bc00 EDX:00181bfc > ESI:0058ad38 EDI:00000000 > Stack dump: > 0x0033f518: 00407eab 00182c18 004363fc 00000000 > 0x0033f528: 0043e4c0 0043fac4 00000000 0040814e > 0x0033f538: 00181bf8 00000003 7da58b08 0033fa20 > 0x0033f548: 7da5af6c 0058ad38 00007734 90234a8d > 0x0033f558: f7bdb63f 00003020 0033f658 7da4bc9f > 0x0033f568: 7e4fa15f 7e4c2cd0 0033fa78 0042f0bb > Backtrace: > =>1 0x00000000 (0x0058b2a8) > 2 0x00000000 (0x00182c18) > 3 0x00000001 (0x7da5bc00) > 4 0x00000000 (0x00000000) > 0x00000000: addb %al,0x0(%eax) > Modules: > Module Address Debug info Name (96 modules) > PE 400000- 464000 Deferred setting > ELF 7b800000-7b927000 Deferred kernel32<elf> > \-PE 7b820000-7b927000 \ kernel32 > ELF 7bc00000-7bc96000 Deferred ntdll<elf> > \-PE 7bc10000-7bc96000 \ ntdll > ELF 7bf00000-7bf03000 Deferred <wine-loader> > ELF 7ccdb000-7ccf0000 Deferred midimap<elf> > \-PE 7cce0000-7ccf0000 \ midimap > ELF 7ccf0000-7cd16000 Deferred msacm32<elf> > \-PE 7cd00000-7cd16000 \ msacm32 > ELF 7cd16000-7cd2e000 Deferred msacm32<elf> > \-PE 7cd20000-7cd2e000 \ msacm32 > ELF 7cd2e000-7cd6a000 Deferred wineoss<elf> > \-PE 7cd40000-7cd6a000 \ wineoss > ELF 7cd6a000-7cdbb000 Deferred libgcrypt.so.11 > ELF 7cdbb000-7cdd0000 Deferred libtasn1.so.3 > ELF 7cdd0000-7cdfe000 Deferred libcrypt.so.1 > ELF 7ce11000-7ce81000 Deferred libgnutls.so.13 > ELF 7ce81000-7ceb2000 Deferred libcups.so.2 > ELF 7d1e7000-7d1eb000 Deferred libgpg-error.so.0 > ELF 7d1eb000-7d21d000 Deferred uxtheme<elf> > \-PE 7d1f0000-7d21d000 \ uxtheme > ELF 7d21f000-7d224000 Deferred libxfixes.so.3 > ELF 7d224000-7d22d000 Deferred libxcursor.so.1 > ELF 7d22d000-7d233000 Deferred libxrandr.so.2 > ELF 7d233000-7d23b000 Deferred libxrender.so.1 > ELF 7d23b000-7d23e000 Deferred libxinerama.so > ELF 7d764000-7d7f3000 Deferred winex11<elf> > \-PE 7d770000-7d7f3000 \ winex11 > ELF 7d89c000-7d8bc000 Deferred libexpat.so.1 > ELF 7d8bc000-7d8e7000 Deferred libfontconfig.so.1 > ELF 7d8e7000-7d8fb000 Deferred libz.so.1 > ELF 7d8fb000-7d966000 Deferred libfreetype.so.6 > ELF 7d966000-7d97a000 Deferred oleacc<elf> > \-PE 7d970000-7d97a000 \ oleacc > ELF 7d97a000-7d997000 Deferred imm32<elf> > \-PE 7d980000-7d997000 \ imm32 > ELF 7d997000-7da26000 Deferred winmm<elf> > \-PE 7d9a0000-7da26000 \ winmm > ELF 7da26000-7da5c000 Deferred dinput<elf> > \-PE 7da30000-7da5c000 \ dinput > ELF 7da5c000-7da75000 Deferred dinput8<elf> > \-PE 7da60000-7da75000 \ dinput8 > ELF 7dad8000-7e35e000 Deferred libglcore.so.1 > ELF 7e35e000-7e3de000 Deferred libglu.so.1 > ELF 7e3de000-7e46a000 Deferred libgl.so.1 > ELF 7e46a000-7e55b000 Deferred libx11.so.6 > ELF 7e55b000-7e569000 Deferred libxext.so.6 > ELF 7e569000-7e581000 Deferred libice.so.6 > ELF 7e581000-7e642000 Deferred wined3d<elf> > \-PE 7e590000-7e642000 \ wined3d > ELF 7e642000-7e66a000 Deferred d3d8<elf> > \-PE 7e650000-7e66a000 \ d3d8 > ELF 7e66a000-7e705000 Deferred oleaut32<elf> > \-PE 7e680000-7e705000 \ oleaut32 > ELF 7e705000-7e718000 Deferred libresolv.so.2 > ELF 7e718000-7e736000 Deferred iphlpapi<elf> > \-PE 7e720000-7e736000 \ iphlpapi > ELF 7e736000-7e78b000 Deferred rpcrt4<elf> > \-PE 7e740000-7e78b000 \ rpcrt4 > ELF 7e78b000-7e828000 Deferred ole32<elf> > \-PE 7e7a0000-7e828000 \ ole32 > ELF 7e828000-7e84a000 Deferred oledlg<elf> > \-PE 7e830000-7e84a000 \ oledlg > ELF 7e84a000-7e87d000 Deferred winspool<elf> > \-PE 7e850000-7e87d000 \ winspool > ELF 7e87d000-7e939000 Deferred comctl32<elf> > \-PE 7e890000-7e939000 \ comctl32 > ELF 7e939000-7e991000 Deferred shlwapi<elf> > \-PE 7e950000-7e991000 \ shlwapi > ELF 7e991000-7ea8c000 Deferred shell32<elf> > \-PE 7e9a0000-7ea8c000 \ shell32 > ELF 7ea8c000-7eb2c000 Deferred comdlg32<elf> > \-PE 7ea90000-7eb2c000 \ comdlg32 > ELF 7eb2c000-7eb73000 Deferred advapi32<elf> > \-PE 7eb40000-7eb73000 \ advapi32 > ELF 7eb73000-7eb7f000 Deferred libgcc_s.so.1 > ELF 7eb81000-7eb86000 Deferred libxdmcp.so.6 > ELF 7eb86000-7eb89000 Deferred libxau.so.6 > ELF 7eb89000-7eb92000 Deferred libsm.so.6 > ELF 7ec7c000-7ed3a000 Deferred gdi32<elf> > \-PE 7ec90000-7ed3a000 \ gdi32 > ELF 7ed3a000-7ee76000 Deferred user32<elf> > \-PE 7ed60000-7ee76000 \ user32 > ELF 7efa4000-7efaf000 Deferred libnss_files.so.2 > ELF 7efaf000-7efc6000 Deferred libnsl.so.1 > ELF 7efc6000-7efed000 Deferred libm.so.6 > ELF 7efed000-7eff7000 Deferred libnss_nis.so.2 > ELF 7eff7000-7f000000 Deferred libnss_compat.so.2 > ELF b7d51000-b7d56000 Deferred libxxf86vm.so.1 > ELF b7d57000-b7d5b000 Deferred libdl.so.2 > ELF b7d5b000-b7e9c000 Deferred libc.so.6 > ELF b7e9d000-b7eb4000 Deferred libpthread.so.0 > ELF b7eb4000-b7eb6000 Deferred libnvidia-tls.so.1 > ELF b7ec7000-b7fd8000 Deferred libwine.so.1 > ELF b7fda000-b7ff5000 Deferred ld-linux.so.2 > Threads: > process tid prio (all id:s are in hex) > 0000000a > 0000000c 0 > 0000000b 0 > 00000008 (D) C:\Program Files\KONAMI\Pro Evolution Soccer 3\setting.exe > 0000000d 0 > 00000009 0 <== > > > >

May 3, 2007

Re: Unsecured API functions

by Frank Richter

On 03.05.2007 22:00, Tom Spear wrote: > Do we implement secured versions of other functions, and if > not, how come? The *_s functions are provided by the C runtime library (ie msvcr80.dll). So Wine probably doesn't need to implement them (at least not until they pop up in, say, msvcrt.dll). -f.r.

May 3, 2007

Re: Boundary test cases for SystemTimeToFileTime and GetDateFormat

by James Hawkins

On 5/3/07, Bill Medland <billmedland(a)shaw.ca> wrote: > Bill Medland (billmedland(a)shaw.ca) > Lower boundary test cases for SystemTimeToFileTime and GetDateFormat > > Index: wine/dlls/kernel32/tests/locale.c > =================================================================== > RCS file: /home/wine/wine/dlls/kernel32/tests/locale.c,v > retrieving revision 1.11 > diff -u -r1.11 locale.c > --- wine/dlls/kernel32/tests/locale.c 2 Apr 2007 11:24:36 -0000 1.11 > +++ wine/dlls/kernel32/tests/locale.c 3 May 2007 22:21:55 -0000 > @@ -424,6 +424,34 @@ > STRINGSW("dddd d MMMM yyyy","Wednesday 23 October 2002"); /* Incorrect DOW and time */ > ret = GetDateFormatW (lcid, 0, &curtime, input, buffer, COUNTOF(buffer)); > EXPECT_VALID; EXPECT_LENW; EXPECT_EQW; > + > + /* Limit tests */ > + > + curtime.wYear = 1601; > + curtime.wMonth = 1; > + curtime.wDay = 1; > + curtime.wDayOfWeek = 0; /* Irrelevant */ > + curtime.wHour = 0; > + curtime.wMinute = 0; > + curtime.wSecond = 0; > + curtime.wMilliseconds = 0; > + STRINGSW("dddd d MMMM yyyy","Monday 1 January 1601"); > + SetLastError(0xdeadbeef); > + ret = GetDateFormatW (lcid, 0, &curtime, input, buffer, COUNTOF(buffer)); > + EXPECT_VALID; EXPECT_LENW; EXPECT_EQW; > + > + curtime.wYear = 1600; > + curtime.wMonth = 12; > + curtime.wDay = 31; > + curtime.wDayOfWeek = 0; /* Irrelevant */ > + curtime.wHour = 23; > + curtime.wMinute = 59; > + curtime.wSecond = 59; > + curtime.wMilliseconds = 999; > + STRINGSW("dddd d MMMM yyyy","Friday 31 December 1600"); > + SetLastError(0xdeadbeef); > + ret = GetDateFormatW (lcid, 0, &curtime, input, buffer, COUNTOF(buffer)); > + EXPECT_INVALID; > } > > > Index: wine/dlls/kernel32/tests/time.c > =================================================================== > RCS file: /home/wine/wine/dlls/kernel32/tests/time.c,v > retrieving revision 1.3 > diff -u -r1.3 time.c > --- wine/dlls/kernel32/tests/time.c 4 Jan 2007 10:46:26 -0000 1.3 > +++ wine/dlls/kernel32/tests/time.c 3 May 2007 22:22:04 -0000 > @@ -73,6 +73,23 @@ > (st).wSecond = 32; \ > (st).wMilliseconds = 123; > > +#define SETUP_ZEROTIME(st) \ > + (st).wYear = 1601; \ > + (st).wMonth = 1; \ > + (st).wDay = 1; \ > + (st).wHour = 0; \ > + (st).wMinute = 0; \ > + (st).wSecond = 0; \ > + (st).wMilliseconds = 0; > + > +#define SETUP_EARLY(st) \ > + (st).wYear = 1600; \ > + (st).wMonth = 12; \ > + (st).wDay = 31; \ > + (st).wHour = 23; \ > + (st).wMinute = 59; \ > + (st).wSecond = 59; \ > + (st).wMilliseconds = 999; > > > static void test_conversions(void) > @@ -82,6 +99,12 @@ > > memset(&ft,0,sizeof ft); > > + SETUP_EARLY(st) > + ok ((!SystemTimeToFileTime(&st, &ft) && GetLastError() == ERROR_INVALID_PARAMETER), "Conversion failed EARLY\n"); > + > + SETUP_ZEROTIME(st) > + ok (SystemTimeToFileTime(&st, &ft) && ft.dwHighDateTime == 0 && ft.dwLowDateTime == 0, "Conversion failed ZERO_TIME\n"); > + You need to check each part of those conditions separately in their own ok()'s. -- James Hawkins

May 3, 2007

Re: Unsecured API functions

by Tom Spear

On 5/3/07, Kai Blin <kai.blin(a)gmail.com> wrote: > On Thursday 03 May 2007 23:16, Tom Spear wrote: > > Noone should use gets(). There are lots of better alternatives. For the other > deprecated functions, there are ways to check that the input is valid before > calling it, iirc. I agree that nobody uses it, and that there are better alternatives, I was just using it as an example. You are correct, though about there being ways to check the input. > As far as imnplementing the secured functions in Wine, I have yet to see a > program that's failing because it tries to use one of them. I do agree that we shouldnt implement it until a program fails. I know I worded the email wrong. I was actually just wondering if we had any plans to implement them in the future and if we had the resources to do that. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 3, 2007

Re: Unsecured API functions

by Kai Blin

On Thursday 03 May 2007 23:16, Tom Spear wrote: > Otherwise I assume there would be thousands of buffer overflows that > (malicious) people would exploit. Noone should use gets(). There are lots of better alternatives. For the other deprecated functions, there are ways to check that the input is valid before calling it, iirc. As far as imnplementing the secured functions in Wine, I have yet to see a program that's failing because it tries to use one of them. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ Samba team member http://us1.samba.org/samba/team/ -- Will code for cotton.

May 3, 2007

Testing and VarBstrFromDate (was Re: OLE2A)

by Bill Medland

On Thu, 2007-03-05 at 07:29 -0700, Bill Medland wrote: > On Thu, 2007-03-05 at 07:49 +0200, Marcus Meissner wrote: > > On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote: > > > Does anyone know where a call to OLE2A is going to enter wine? > > > Presumably OLE2A returning null means that the thread ran out of stack > > > space? > > > > What is OLE2A? I do not see it mentioned anyewhere in the Wine source. > > > > Any more debugging output? > > > > Ciao, Marcus > Hi Marcus, thanks for taking interest. > > A little late now, I think. The problem is not where I thought it was. > > OLE2A is a Microsoft macro used to convert e.g. a BSTR to a char *, > allocating memory on the stack and calling one of the wide-to-narrow > conversions. > > Our program was behaving quite strangely, throwing an exception from > some code that should not throw an exception. > > I traced it down to some code that did an OLE2A on a BSTR, called strlen > on the return and then passed the same narrow string to a function. > The problem occurred when the OLE2A returned a null pointer. Due to an > oversight I thought the BSTR was non-null and assumed that somehow the > underlying alloca must be returning null (i.e. was detecting out-of- > stack-space). > > Now I discover that the BSTR itself was also NULL so that makes sense. > > I presume what happens is all that magic that traps the segment > violation on strlen(0) didn't quite handle whatever optimised code was > being generated for our case. > > However what I am also investigating is where the original NULL BSTR > came from; possibly a defect in VariantChangeTypeEx. > Actually VariantChangeType was returning E_INVALIDPARAM and a VT_EMPTY and the caller wasn't checking the result. However I think VariantChangeType was wrong in this case. > Bill > > > So. 1. Am I misunderstanding something about the tests these days? (I am about to add two edge tests on SystemTimeToFileTime in time.c and GetDateFormatW in locale.c) I go into dlls/kernel32/tests and make tests and it fails (change.c, locale.c) Should that disconcert me? 2. How to fix the VarBstrFromDate? VarBstrFromDate(-657434.0 (DATE_MIN), 0x409, 0x80000000, wherever) fails because VariantTimeToSystemTime successfully converts that to 1/1/100 but then VarBstrFromDate tries to format that using GetDateFormat, which is not feasible because the SystemTime is out of range. Is there an existing low level routine that can handle the conversion for such a small date? Bill

May 3, 2007

Re: Unsecured API functions

by Tom Spear

On 5/3/07, Marcus Meissner <marcus(a)jet.franken.de> wrote: > wine is not using gets() at all, insofar there is no risk from it. That much I knew, however we do use strcpy (especially in msi), and that is another one that has been deprecated ("banned").. See http://msdn2.microsoft.com/en-us/library/bb288454.aspx for the complete list.. > It would be quite hard to convert gets -> gets_s by magic ;) hmm, I thought so, and re-reading the page, it appears that it is actually more of a proposal, than a list of api's that have actually already been deprecated, however if msdn has an article from the sdl that pushes for the deprecation of non-strsafe functions, I think we should take that seriously, and at least investigate the difficulty (I'm not pushing for it to be replaced anywhere in the code right now, because we are already spread too thin). -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 3, 2007

Re: Unsecured API functions

by Marcus Meissner

On Thu, May 03, 2007 at 04:16:31PM -0500, Tom Spear wrote: > On 5/3/07, Robert Shearman <rob(a)codeweavers.com> wrote: > >Tom Spear wrote: > >> I was writing up a Hello World with input program for a demonstration > >> for a non-developer coworker last week, and used the unsecured getch() > >> and got the standard warning about how it was unsecured and dangerous > >> to use that. That prompted me to look up the basic secured functions > >> on the MS website, and compare to wine code. According to MSDN, > >> things like gets have been replaced with gets_s. However, as far as I > >> can tell, wine still only implements gets for Windows programs to > >> use.. Do we implement secured versions of other functions, and if > >> not, how come? > > > >Q: Why doesn't Wine implement X? > >A: Because not many programs use it and no-one has felt interested in > >implementing it for fun. > > So in other words, most programs use insecure functions (like gets) > instead of using secure functions (like gets_s), leaving themselves > vulnerable to all sorts of buffer overflows? I wonder if microsoft > doesn't silently convert gets calls to gets_s calls, then, and maybe > didn't document that? > > Otherwise I assume there would be thousands of buffer overflows that > (malicious) people would exploit. > > I understand that most programs dont use either of those functions, > but there are others that are used by nearly every program that ms > deprecated in favor of secure versions. wine is not using gets() at all, insofar there is no risk from it. It would be quite hard to convert gets -> gets_s by magic ;) Ciao, Marcus

May 3, 2007

tools/winegcc solaris link options patch

by sol11x86＠comcast.net

Please comment on this patch: This patch adds two options to toool/winegcc to allow Solaris linker flags to be passed through and recognized. Prior to this patch, libraries compiled with winegcc (despite overloading every link related env variable I could think of), had a single RPATH when evaulated with elfdump (which was the primary library from the compiler). The effect was that I was required to set an LD_LIBRARY_PATH prior to running any of the wine applications, since the RPATH was not fully populated. With this patch, and proper configuration of LDFLAGS, I am now able to build wine on Solaris without having to resort to an LD_LIBRARY_PATH when I run wine. The two flags that are added to winegcc.c are: -R <libdir> -z <linker flags> (-z allows me to control the link phase a little better for performance reasons). Thanks to Steleman who quickly recognized the problem, despite the facts were staring me in the face. Ben

May 3, 2007

Re: Unsecured API functions

by Tom Spear

On 5/3/07, Robert Shearman <rob(a)codeweavers.com> wrote: > Tom Spear wrote: > > I was writing up a Hello World with input program for a demonstration > > for a non-developer coworker last week, and used the unsecured getch() > > and got the standard warning about how it was unsecured and dangerous > > to use that. That prompted me to look up the basic secured functions > > on the MS website, and compare to wine code. According to MSDN, > > things like gets have been replaced with gets_s. However, as far as I > > can tell, wine still only implements gets for Windows programs to > > use.. Do we implement secured versions of other functions, and if > > not, how come? > > Q: Why doesn't Wine implement X? > A: Because not many programs use it and no-one has felt interested in > implementing it for fun. So in other words, most programs use insecure functions (like gets) instead of using secure functions (like gets_s), leaving themselves vulnerable to all sorts of buffer overflows? I wonder if microsoft doesn't silently convert gets calls to gets_s calls, then, and maybe didn't document that? Otherwise I assume there would be thousands of buffer overflows that (malicious) people would exploit. I understand that most programs dont use either of those functions, but there are others that are used by nearly every program that ms deprecated in favor of secure versions. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 3, 2007

Re: Unsecured API functions

by Robert Shearman

Tom Spear wrote: > I was writing up a Hello World with input program for a demonstration > for a non-developer coworker last week, and used the unsecured getch() > and got the standard warning about how it was unsecured and dangerous > to use that. That prompted me to look up the basic secured functions > on the MS website, and compare to wine code. According to MSDN, > things like gets have been replaced with gets_s. However, as far as I > can tell, wine still only implements gets for Windows programs to > use.. Do we implement secured versions of other functions, and if > not, how come? Q: Why doesn't Wine implement X? A: Because not many programs use it and no-one has felt interested in implementing it for fun. -- Rob Shearman

May 3, 2007

dinput : crash of Pro Evolution Soccer 3 with a joystick

by Sébastien GRIPON

Hi, I try to play to Pro Evolution Soccer 3 on my Ubuntu Fesity Fawn and it's not far to be possible. Every wine release brings a lots of wined3d improvements and pes3 is almost playable. Many textures are missing, but it's on a good way. Congratulations ! However, I have a problem with my joystick. I have a Microsoft Sidewinder and a Thrustmaster and when any of them is plugged on an USB port, the exe pes3.exe or the PES configuration tool setting.exe crash. This crash doesn't occur when joysticks are not pluggued. I tried to debug this crash, but it is a very hard work. I think dinput is involved but I can't be sure. If you're interesting in this game, this is the crash dump. Thank you, Seb. $ wine setting.exe fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE wine: Unhandled page fault on read access to 0x00000000 at address (nil) (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:00000000 ESP:0033f518 EBP:0058b2a8 EFLAGS:00210246( - 00 -RIZP1) EAX:00182c18 EBX:00000000 ECX:7da5bc00 EDX:00181bfc ESI:0058ad38 EDI:00000000 Stack dump: 0x0033f518: 00407eab 00182c18 004363fc 00000000 0x0033f528: 0043e4c0 0043fac4 00000000 0040814e 0x0033f538: 00181bf8 00000003 7da58b08 0033fa20 0x0033f548: 7da5af6c 0058ad38 00007734 90234a8d 0x0033f558: f7bdb63f 00003020 0033f658 7da4bc9f 0x0033f568: 7e4fa15f 7e4c2cd0 0033fa78 0042f0bb Backtrace: =>1 0x00000000 (0x0058b2a8) 2 0x00000000 (0x00182c18) 3 0x00000001 (0x7da5bc00) 4 0x00000000 (0x00000000) 0x00000000: addb %al,0x0(%eax) Modules: Module Address Debug info Name (96 modules) PE 400000- 464000 Deferred setting ELF 7b800000-7b927000 Deferred kernel32<elf> \-PE 7b820000-7b927000 \ kernel32 ELF 7bc00000-7bc96000 Deferred ntdll<elf> \-PE 7bc10000-7bc96000 \ ntdll ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7ccdb000-7ccf0000 Deferred midimap<elf> \-PE 7cce0000-7ccf0000 \ midimap ELF 7ccf0000-7cd16000 Deferred msacm32<elf> \-PE 7cd00000-7cd16000 \ msacm32 ELF 7cd16000-7cd2e000 Deferred msacm32<elf> \-PE 7cd20000-7cd2e000 \ msacm32 ELF 7cd2e000-7cd6a000 Deferred wineoss<elf> \-PE 7cd40000-7cd6a000 \ wineoss ELF 7cd6a000-7cdbb000 Deferred libgcrypt.so.11 ELF 7cdbb000-7cdd0000 Deferred libtasn1.so.3 ELF 7cdd0000-7cdfe000 Deferred libcrypt.so.1 ELF 7ce11000-7ce81000 Deferred libgnutls.so.13 ELF 7ce81000-7ceb2000 Deferred libcups.so.2 ELF 7d1e7000-7d1eb000 Deferred libgpg-error.so.0 ELF 7d1eb000-7d21d000 Deferred uxtheme<elf> \-PE 7d1f0000-7d21d000 \ uxtheme ELF 7d21f000-7d224000 Deferred libxfixes.so.3 ELF 7d224000-7d22d000 Deferred libxcursor.so.1 ELF 7d22d000-7d233000 Deferred libxrandr.so.2 ELF 7d233000-7d23b000 Deferred libxrender.so.1 ELF 7d23b000-7d23e000 Deferred libxinerama.so ELF 7d764000-7d7f3000 Deferred winex11<elf> \-PE 7d770000-7d7f3000 \ winex11 ELF 7d89c000-7d8bc000 Deferred libexpat.so.1 ELF 7d8bc000-7d8e7000 Deferred libfontconfig.so.1 ELF 7d8e7000-7d8fb000 Deferred libz.so.1 ELF 7d8fb000-7d966000 Deferred libfreetype.so.6 ELF 7d966000-7d97a000 Deferred oleacc<elf> \-PE 7d970000-7d97a000 \ oleacc ELF 7d97a000-7d997000 Deferred imm32<elf> \-PE 7d980000-7d997000 \ imm32 ELF 7d997000-7da26000 Deferred winmm<elf> \-PE 7d9a0000-7da26000 \ winmm ELF 7da26000-7da5c000 Deferred dinput<elf> \-PE 7da30000-7da5c000 \ dinput ELF 7da5c000-7da75000 Deferred dinput8<elf> \-PE 7da60000-7da75000 \ dinput8 ELF 7dad8000-7e35e000 Deferred libglcore.so.1 ELF 7e35e000-7e3de000 Deferred libglu.so.1 ELF 7e3de000-7e46a000 Deferred libgl.so.1 ELF 7e46a000-7e55b000 Deferred libx11.so.6 ELF 7e55b000-7e569000 Deferred libxext.so.6 ELF 7e569000-7e581000 Deferred libice.so.6 ELF 7e581000-7e642000 Deferred wined3d<elf> \-PE 7e590000-7e642000 \ wined3d ELF 7e642000-7e66a000 Deferred d3d8<elf> \-PE 7e650000-7e66a000 \ d3d8 ELF 7e66a000-7e705000 Deferred oleaut32<elf> \-PE 7e680000-7e705000 \ oleaut32 ELF 7e705000-7e718000 Deferred libresolv.so.2 ELF 7e718000-7e736000 Deferred iphlpapi<elf> \-PE 7e720000-7e736000 \ iphlpapi ELF 7e736000-7e78b000 Deferred rpcrt4<elf> \-PE 7e740000-7e78b000 \ rpcrt4 ELF 7e78b000-7e828000 Deferred ole32<elf> \-PE 7e7a0000-7e828000 \ ole32 ELF 7e828000-7e84a000 Deferred oledlg<elf> \-PE 7e830000-7e84a000 \ oledlg ELF 7e84a000-7e87d000 Deferred winspool<elf> \-PE 7e850000-7e87d000 \ winspool ELF 7e87d000-7e939000 Deferred comctl32<elf> \-PE 7e890000-7e939000 \ comctl32 ELF 7e939000-7e991000 Deferred shlwapi<elf> \-PE 7e950000-7e991000 \ shlwapi ELF 7e991000-7ea8c000 Deferred shell32<elf> \-PE 7e9a0000-7ea8c000 \ shell32 ELF 7ea8c000-7eb2c000 Deferred comdlg32<elf> \-PE 7ea90000-7eb2c000 \ comdlg32 ELF 7eb2c000-7eb73000 Deferred advapi32<elf> \-PE 7eb40000-7eb73000 \ advapi32 ELF 7eb73000-7eb7f000 Deferred libgcc_s.so.1 ELF 7eb81000-7eb86000 Deferred libxdmcp.so.6 ELF 7eb86000-7eb89000 Deferred libxau.so.6 ELF 7eb89000-7eb92000 Deferred libsm.so.6 ELF 7ec7c000-7ed3a000 Deferred gdi32<elf> \-PE 7ec90000-7ed3a000 \ gdi32 ELF 7ed3a000-7ee76000 Deferred user32<elf> \-PE 7ed60000-7ee76000 \ user32 ELF 7efa4000-7efaf000 Deferred libnss_files.so.2 ELF 7efaf000-7efc6000 Deferred libnsl.so.1 ELF 7efc6000-7efed000 Deferred libm.so.6 ELF 7efed000-7eff7000 Deferred libnss_nis.so.2 ELF 7eff7000-7f000000 Deferred libnss_compat.so.2 ELF b7d51000-b7d56000 Deferred libxxf86vm.so.1 ELF b7d57000-b7d5b000 Deferred libdl.so.2 ELF b7d5b000-b7e9c000 Deferred libc.so.6 ELF b7e9d000-b7eb4000 Deferred libpthread.so.0 ELF b7eb4000-b7eb6000 Deferred libnvidia-tls.so.1 ELF b7ec7000-b7fd8000 Deferred libwine.so.1 ELF b7fda000-b7ff5000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a 0000000c 0 0000000b 0 00000008 (D) C:\Program Files\KONAMI\Pro Evolution Soccer 3\setting.exe 0000000d 0 00000009 0 <==

May 3, 2007

Unsecured API functions

by Tom Spear

I was writing up a Hello World with input program for a demonstration for a non-developer coworker last week, and used the unsecured getch() and got the standard warning about how it was unsecured and dangerous to use that. That prompted me to look up the basic secured functions on the MS website, and compare to wine code. According to MSDN, things like gets have been replaced with gets_s. However, as far as I can tell, wine still only implements gets for Windows programs to use.. Do we implement secured versions of other functions, and if not, how come? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 3, 2007

Re: Implement MsiBreak Feature - Bug 8243

by James Hawkins

On 5/2/07, EA Durbin <ead1234(a)hotmail.com> wrote: > patch created by Anastasius Focht for Bug 8243. > + /* check "MsiBreak" environment variable */ + if( GetEnvironmentVariableW( envMsiBreakW, envMsiBreakValueW, MAX_PATH)) + { I think we need more investigation into this before accepting this patch. One of the things that needs to be checked is whether the windows installer checks the environment variable every single time a custom action is called, or if the environment variable is stored at the beginning of the installation and just the custom action name is checked every time a custom action is called. This can be tested on windows by setting MsiBreak to a certain custom action, and then change the environment variable to a different custom action while the message box is still asking to break. If the installer breaks on the next custom action, we'll know that it checks the environment variable each time. -- James Hawkins

May 3, 2007

Re: Implement MsiBreak Feature - Bug 8243

by Peter Oberndorfer

On Thursday 03 May 2007 05:45, EA Durbin wrote: Hi, > patch created by Anastasius Focht for Bug 8243. > >+#include <sys/types.h> /* for getpid() */ >+#include <unistd.h> /* for getpid() */ Do we really need to write out unix pid? AFAIK Winedbg can attach to windows process IDs just fine. >+ if( MessageBoxW( NULL, dbgMsgW, CustomActionName, MB_OKCANCEL) == IDOK) >+ { >+ return TRUE; >+ } nitpick: maybe remove {} to be consistent with rest of file? >+ if( IsMsiBreak( info->target)) >+ DebugBreak(); extra nitpick: maybe remove space before argument or place additional space before closing ) like foo( baz ); / foo(baz); It also seems like the patch is line wrapped. Greetings Peter

May 3, 2007

Re: [4/5] WineD3D: Implement vertex blending using GL_ARB_vertex_blend

by H. Verbeet

Actually, I only thought about this just now, but you should also call glDisableClientState(GL_WEIGHT_ARRAY); in unloadVertexData().

May 3, 2007

Re: Some Spanish translation updates

by Alexandre Julliard

José Manuel Ferrer Ortiz <jmfo1982(a)yahoo.es> writes: > By the way, I've changed the license of the files > 'oledlg/oledlg_Es.rc' and 'shdoclc/Es.rc' (I was the creator of > these two files) to LPGL version 2.1 (and not any later). Please don't do that. All of Wine should be under the same license, otherwise it will create major confusion. -- Alexandre Julliard julliard(a)winehq.org

May 3, 2007

Re: OLE2A

by Bill Medland

On Thu, 2007-03-05 at 07:49 +0200, Marcus Meissner wrote: > On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote: > > Does anyone know where a call to OLE2A is going to enter wine? > > Presumably OLE2A returning null means that the thread ran out of stack > > space? > > What is OLE2A? I do not see it mentioned anyewhere in the Wine source. > > Any more debugging output? > > Ciao, Marcus Hi Marcus, thanks for taking interest. A little late now, I think. The problem is not where I thought it was. OLE2A is a Microsoft macro used to convert e.g. a BSTR to a char *, allocating memory on the stack and calling one of the wide-to-narrow conversions. Our program was behaving quite strangely, throwing an exception from some code that should not throw an exception. I traced it down to some code that did an OLE2A on a BSTR, called strlen on the return and then passed the same narrow string to a function. The problem occurred when the OLE2A returned a null pointer. Due to an oversight I thought the BSTR was non-null and assumed that somehow the underlying alloca must be returning null (i.e. was detecting out-of- stack-space). Now I discover that the BSTR itself was also NULL so that makes sense. I presume what happens is all that magic that traps the segment violation on strlen(0) didn't quite handle whatever optimised code was being generated for our case. However what I am also investigating is where the original NULL BSTR came from; possibly a defect in VariantChangeTypeEx. Bill

May 3, 2007

Re: What's the long term plan for 64 bit support?

by Alexandre Julliard

Scott Ritchie <scott(a)open-vote.org> writes: > But why have separate packages if the problem lies in wineserver? Once > we figure out how to make wineserver intelligently handle the issue, > then we can package the apps together. Until then, we're best off > packaging just the 32 bit version, since we can't have two wineservers > for two different packages. At the Wine level there's no specific requirement, it should support either one package or two, that's really up to you and to the packaging guidelines for the target platform. All Wine will need is to know where the files are, so the loader and tools know where to find the 32-bit libraries, and the 32-bit loader knows where to find the 64-bit wineserver. -- Alexandre Julliard julliard(a)winehq.org

May 3, 2007

Console output with different codepages - the result.

by Kirill K. Smirnov

> В сообщении от 23 апреля 2007 16:11 вы написали: > > "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > > >> >> The written strings in 866 and 1251 code pages are only readable > > >> >> when output console code page matches the string encoding. > > >> > > > >> > This is in wine. > > >> > In windows only cp866 is readable regardless of ConsoleOutputCP. > > >> > > >> As I said I tested under Windows (XP) only, and SetConsoleOutputCP > > >> does change the behaviour of WriteConsoleA for me. If it wouldn't > > >> I'd call it a bug. > > > > > > I tested under Windows 2003 and SetConsoleOutputCP does NOT change the > > > behaviour of WriteConsoleA for me. > > > Does Windows play us a trick? > > > > No the difference in observed behaviour was caused by the fact that I ran > > the test under FAR, once I run it under cmd.exe I see what you do. > > Ahhh, I understood!!! > > You test does not return codepage back to 866. My version of your test does > it. > Far Manager somehow checks codepage and converts characters accordingly. > I've removed the last convertion back to cp866 and observed the same > behaviur as you. > > Thus, I can proclaim WriteConsoleA buggy. The final result: 1) WriteConsoleA is OK - while preparing the tests the truth was revealed. 2) The main issue is hidden in Windows console renderer. I've tried three different ways: windowed with TrueType font (lucida), windowed with Fixedsys font and fullscreen mode. a) Lucida Console font: the behaviour in wine and windows the same. (Dmitry observed this). b) Fixedsys: wine - the same as with Lucida Console font - nothing changed. windows - only cp866 is OK. (I observed this) c) Fullscreen. In this case font codepage is changed immediately: previously written text is changed. This behaviour in unique for fullscreen mode. Thus I can conclude that console codepages are used by console renderer too, not just by WriteConsoleA. Should this windows behaviour be implemented in wine? I think no, it is too insane and needless. But this should be kept in mind, maybe update docs? -- Kirill

May 3, 2007

Re: [5/5] WineD3D: Software vertex blending

by H. Verbeet

On 03/05/07, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > I think both of you are wrong, and the correct number is 15 + > WINED3DDP_MAXTEXCOORD, True, I only noticed the hardcoded 16, not that the code's actually looping over the strided data rather than actual vertex attributes.

May 3, 2007

Re: OLE2A

by Marcus Meissner

On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote: > Does anyone know where a call to OLE2A is going to enter wine? > Presumably OLE2A returning null means that the thread ran out of stack > space? What is OLE2A? I do not see it mentioned anyewhere in the Wine source. Any more debugging output? Ciao, Marcus

May 3, 2007

Re: What's the long term plan for 64 bit support?

by Scott Ritchie

On Wed, 2007-05-02 at 21:54 -0400, Steven Edwards wrote: > On 5/2/07, Scott Ritchie <scott(a)open-vote.org> wrote: > > In the (distant) future, will we support building Wine with both 64 bit > > and 32 bit libraries, and then the same Wine installation will run both > > 64 bit and 32 bit apps? As I understand it, this is the way Windows > > does in its 64 bit versions. > > > > > > I ask because there's a question of how to name the Wine packages for > > the 64 bit distribution - there's a standard of naming 32 bit packages > > something like "wine32", but if we're eventually going to have a unified > > multiarch package then we can still go with just keeping it as "wine" > > Its an interesting question. Do we rebuild everything twice and > package it once? What if you've got a 64bit app that expects to be > able to CreateProcess on a win32 application for legacy purposes and > let the Windows loader figure it out? How is wineserver going to > handle that? I agree with making separate packages like wine32 and > wine64 as we try very hard to emulate mingw32 when it comes to source > porting so it makes since to have the package name and platform names > follow the same standard. > But why have separate packages if the problem lies in wineserver? Once we figure out how to make wineserver intelligently handle the issue, then we can package the apps together. Until then, we're best off packaging just the 32 bit version, since we can't have two wineservers for two different packages. Thanks, Scott Ritchie

May 2, 2007

Re: What's the long term plan for 64 bit support?

by Steven Edwards

On 5/2/07, Scott Ritchie <scott(a)open-vote.org> wrote: > In the (distant) future, will we support building Wine with both 64 bit > and 32 bit libraries, and then the same Wine installation will run both > 64 bit and 32 bit apps? As I understand it, this is the way Windows > does in its 64 bit versions. > > > I ask because there's a question of how to name the Wine packages for > the 64 bit distribution - there's a standard of naming 32 bit packages > something like "wine32", but if we're eventually going to have a unified > multiarch package then we can still go with just keeping it as "wine" Its an interesting question. Do we rebuild everything twice and package it once? What if you've got a 64bit app that expects to be able to CreateProcess on a win32 application for legacy purposes and let the Windows loader figure it out? How is wineserver going to handle that? I agree with making separate packages like wine32 and wine64 as we try very hard to emulate mingw32 when it comes to source porting so it makes since to have the package name and platform names follow the same standard. -- 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 2, 2007

Re: [5/5] WineD3D: Software vertex blending

by Ivan Gyurdiev

H. Verbeet wrote: >> + for(i = 0; i < 16 /* Max vertex attribs */; i++) { > I think you should be using MAX_ATTRIBS there. > > Changing the strided data like that in drawPrimitive looks rather > hacky to me. > > > You cannot access the strided data by both named approach (u.s.something) and indexed approach. The two are completely independent strided formats - one is used for the fixed pipeline, and the other is used for the shader pipeline. I think both of you are wrong, and the correct number is 15 + WINED3DDP_MAXTEXCOORD, which is the bigger of the two unioned together. Only modifying the first 16 will break: normal2, tangent, binormal, tessFactor, fog, depth, sample in the fixed pipeline case (true, I don't see these being used anywhere right now ...). Please leave writing of the strided data to the functions designed for this purpose. Ivan

May 2, 2007

Re: dbghelp performance

by Markus Amsler

Eric Pouech wrote: > Markus Amsler a écrit : >> I've played around with dbghelp performance. My test case was >> breaking at an unknown symbol (break gaga) while WoW was loaded in >> the debugger (wine winedbg WoW.exe). The time was hand stopped, >> memory usage measured with ps -AF and looked at the RSS column. >> >> Test Time(s) Memory Usage(MB) >> current git 4.5 54 >> pool_heap.patch 4.5 63 >> process_heap.patch 4.5 126 >> insert_first.patch 4.5 54 >> current git, r300 115 146 >> pool_heap.patch, r300 17 119 >> process_heap.patch, r300 17 260 >> insert_first.patch, r300 27 167 >> >> insert_first is the patch from Eric Pouech. >> r300 means with the debug version of Mesas r300_dri.so, which has a >> total compilation unit size of around 9.2M (compared to the second >> biggest Wines user32 with 1.1M). >> >> Conclusions: >> - current git wins with small debug files (<2M or so), pool_heap wins >> with bigger files. insert_first, process_heap are out. >> - small pools have less memory overhead than small heaps >> - big pools have more memory overhead than big heaps. >> - big pools are a lot slower than big heaps. > thanks for the testings & timings ! > > you're also missing a couple of elements: > - for the memory overhead, in the first case you consider 50 MB > (roughly) over 10 or 20 modules while in your r300 case the impact > (and memory difference) is only on a single module I'm not sure what's your point is. > - time to unload a module hasn't been computed (it's less used than > loading a module) Unloading is more or less instant in all cases. > what's also strange is that the pool_heap gets lower memory > consumption than the process heap one, which is rather not a natural > result... I wonder if some data haven't been swapped out and aren't > accounted for in RSS The process_heap is the one I sent to wine-patches, which never frees any memory. I've also tested an improved process_heap, which stores the allocated memory pointer in an array and frees it afterwards. Without luck, it's slower and uses more memory the pool_heap. So I don't see a simple solution which only affects storage.c, is equal or better than the current, and is significantly faster at big debug files. Any ideas? Markus

May 2, 2007

What's the long term plan for 64 bit support?

by Scott Ritchie

In the (distant) future, will we support building Wine with both 64 bit and 32 bit libraries, and then the same Wine installation will run both 64 bit and 32 bit apps? As I understand it, this is the way Windows does in its 64 bit versions. I ask because there's a question of how to name the Wine packages for the 64 bit distribution - there's a standard of naming 32 bit packages something like "wine32", but if we're eventually going to have a unified multiarch package then we can still go with just keeping it as "wine" Thanks, Scott Ritchie

May 2, 2007

OLE2A

by Bill Medland

Does anyone know where a call to OLE2A is going to enter wine? Presumably OLE2A returning null means that the thread ran out of stack space? Bill Medland

May 2, 2007

Re: [5/5] WineD3D: Software vertex blending

by H. Verbeet

>+ for(i = 0; i < 16 /* Max vertex attribs */; i++) { I think you should be using MAX_ATTRIBS there. Changing the strided data like that in drawPrimitive looks rather hacky to me.

May 2, 2007

Re: dbghelp performance

by Eric Pouech

Markus Amsler a écrit : > I've played around with dbghelp performance. My test case was breaking > at an unknown symbol (break gaga) while WoW was loaded in the debugger > (wine winedbg WoW.exe). The time was hand stopped, memory usage > measured with ps -AF and looked at the RSS column. > > Test Time(s) Memory Usage(MB) > current git 4.5 54 > pool_heap.patch 4.5 63 > process_heap.patch 4.5 126 > insert_first.patch 4.5 54 > current git, r300 115 146 > pool_heap.patch, r300 17 119 > process_heap.patch, r300 17 260 > insert_first.patch, r300 27 167 > > insert_first is the patch from Eric Pouech. > r300 means with the debug version of Mesas r300_dri.so, which has a > total compilation unit size of around 9.2M (compared to the second > biggest Wines user32 with 1.1M). > > Conclusions: > - current git wins with small debug files (<2M or so), pool_heap wins > with bigger files. insert_first, process_heap are out. > - small pools have less memory overhead than small heaps > - big pools have more memory overhead than big heaps. > - big pools are a lot slower than big heaps. thanks for the testings & timings ! you're also missing a couple of elements: - for the memory overhead, in the first case you consider 50 MB (roughly) over 10 or 20 modules while in your r300 case the impact (and memory difference) is only on a single module - time to unload a module hasn't been computed (it's less used than loading a module) what's also strange is that the pool_heap gets lower memory consumption than the process heap one, which is rather not a natural result... I wonder if some data haven't been swapped out and aren't accounted for in RSS A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 2, 2007

Re: Bug in Advapi32: CryptEnumProviderTypesA and CryptEnumProvidersA

by Eric Pouech

Mounir IDRASSI a écrit : > Should we fill a bugzilla report before submitting the patch? > Thanks. > > > no need for opening the bugzilla entry, just send the patch to wine-patches A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 2, 2007

Bug in Advapi32: CryptEnumProviderTypesA and CryptEnumProvidersA

by Mounir IDRASSI

Hi, During our tests of wine with our cryptographic suite, we have found a bug in the functions CryptEnumProviderTypesA and CryptEnumProvidersA in advapi32 dll: In case of failure, they both report a wrong last error through GetLastError. We have found and corrected the source of the bug: They both call their wide-char counterpart but they don't test the success of this call. The correction is simple: add an if statement and return immediately in case of error. I have attached a small patch with our correction. Should we fill a bugzilla report before submitting the patch? Thanks. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr >From ab7323952138e725700ded1bad4afd17e42717e7 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Wed, 2 May 2007 20:20:59 +0200 Subject: Correct bug in CryptEnumProviderTypesA and CryptEnumProvidersA: They report wrong last error in case of failure --- dlls/advapi32/crypt.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/dlls/advapi32/crypt.c b/dlls/advapi32/crypt.c index 1fd16c3..a7273b9 100644 --- a/dlls/advapi32/crypt.c +++ b/dlls/advapi32/crypt.c @@ -1139,7 +1139,8 @@ BOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD *pdwReserved, TRACE("(%d, %p, %08x, %p, %p, %p)\n", dwIndex, pdwReserved, dwFlags, pdwProvType, pszProvName, pcbProvName); - CryptEnumProvidersW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen); + if(!CryptEnumProvidersW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen)) + return FALSE; if ( pszProvName && !(str = CRYPT_Alloc(strlen)) ) { SetLastError(ERROR_NOT_ENOUGH_MEMORY); @@ -1267,7 +1268,8 @@ BOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD *pdwReserved, TRACE("(%d, %p, %08x, %p, %p, %p)\n", dwIndex, pdwReserved, dwFlags, pdwProvType, pszTypeName, pcbTypeName); - CryptEnumProviderTypesW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen); + if(!CryptEnumProviderTypesW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen)) + return FALSE; if ( pszTypeName && !(str = CRYPT_Alloc(strlen)) ) { SetLastError(ERROR_NOT_ENOUGH_MEMORY); -- 1.4.4.2

May 2, 2007

Re: Any way to get the current code besides git?

by Tom Spear

On 5/2/07, Tom Spear <speeddymon(a)gmail.com> wrote: > On 5/2/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > > "Tom Spear" <speeddymon(a)gmail.com> writes: > > > > > Haven't killed it yet and been waiting for 2 hours.. I'm on a T-3 > > > afaik. Last line that prints before it just sits is: > > > > > > walk 4eea356e2d39f1a958afb4d8f5b54381e8972ecf > > > > This turns out to be a bug in libcurl. It's fixed in libcurl >= 7.16. > > > > -- > > Alexandre Julliard > > julliard(a)winehq.org > > Thanks, I just got the new curl/libcurl, and it just went straight > past the walk 4eea.... I've just added a note to the GitWine wiki > page about it. Just so I know, what is the longest I should expect > to wait between messages before deciding that it has hung, because it > seems to have hung 2 lines down now: > > walk 4eea356e2d39f1a958afb4d8f5b54381e8972ecf > Getting pack 03d06cfa82414ad54614fcb3c633633bf3bfed49 > which contains 7a837e5386cbc23fbadf279073222423a57b4afb > > But I haven't killed it, and I've only waited about 5 minutes so far. Well I waited a while longer, and went about working, and just now checked. It finished. Thanks Alexandre, I never would have figured out it was a race condition, nor that it was libcurl that needed to be upgraded. I just dont have the time to subscribe to another devel list to where I could have reported the problem back when it started. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 2, 2007

Patch question

by Tom Spear

Just curious if there was something wrong with the regedit patch I sent on Friday, or if maybe there is a particular reason that the /C was left out of the code in the first place, that I am missing, and would help me to understand. http://www.winehq.org/pipermail/wine-patches/2007-April/038652.html -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 2, 2007

Re: Any way to get the current code besides git?

by Tom Spear

On 5/2/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > "Tom Spear" <speeddymon(a)gmail.com> writes: > > > Haven't killed it yet and been waiting for 2 hours.. I'm on a T-3 > > afaik. Last line that prints before it just sits is: > > > > walk 4eea356e2d39f1a958afb4d8f5b54381e8972ecf > > This turns out to be a bug in libcurl. It's fixed in libcurl >= 7.16. > > -- > Alexandre Julliard > julliard(a)winehq.org Thanks, I just got the new curl/libcurl, and it just went straight past the walk 4eea.... I've just added a note to the GitWine wiki page about it. Just so I know, what is the longest I should expect to wait between messages before deciding that it has hung, because it seems to have hung 2 lines down now: walk 4eea356e2d39f1a958afb4d8f5b54381e8972ecf Getting pack 03d06cfa82414ad54614fcb3c633633bf3bfed49 which contains 7a837e5386cbc23fbadf279073222423a57b4afb But I haven't killed it, and I've only waited about 5 minutes so far. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 2, 2007

Re: Any way to get the current code besides git?

by Alexandre Julliard

"Tom Spear" <speeddymon(a)gmail.com> writes: > Haven't killed it yet and been waiting for 2 hours.. I'm on a T-3 > afaik. Last line that prints before it just sits is: > > walk 4eea356e2d39f1a958afb4d8f5b54381e8972ecf This turns out to be a bug in libcurl. It's fixed in libcurl >= 7.16. -- Alexandre Julliard julliard(a)winehq.org

May 2, 2007

Re: Adding header files for the implementation of Winscard dll (Smart Cards support)

by Mounir IDRASSI

Sorry, my mistake... I'll definitely be more careful next time. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Dmitry Timoshkov wrote: > This is a notice more for Alexandre this time, but next time please > make sure to send the files with exec bits turned off (755 -> 644). >

May 2, 2007

Re: Adding header files for the implementation of Winscard dll (Smart Cards support)

by Dmitry Timoshkov

"Mounir IDRASSI" <mounir.idrassi(a)idrix.fr> wrote: > diff --git a/include/scarderr.h b/include/scarderr.h > new file mode 100755 > index 0000000..c07833e > --- /dev/null > +++ b/include/scarderr.h ... > diff --git a/include/winscard.h b/include/winscard.h > new file mode 100755 > index 0000000..f302a9f > --- /dev/null > +++ b/include/winscard.h ... > diff --git a/include/winsmcrd.h b/include/winsmcrd.h > new file mode 100755 > index 0000000..cc03a35 > --- /dev/null > +++ b/include/winsmcrd.h This is a notice more for Alexandre this time, but next time please make sure to send the files with exec bits turned off (755 -> 644). -- Dmitry.

May 2, 2007

dbghelp performance

by Markus Amsler

I've played around with dbghelp performance. My test case was breaking at an unknown symbol (break gaga) while WoW was loaded in the debugger (wine winedbg WoW.exe). The time was hand stopped, memory usage measured with ps -AF and looked at the RSS column. Test Time(s) Memory Usage(MB) current git 4.5 54 pool_heap.patch 4.5 63 process_heap.patch 4.5 126 insert_first.patch 4.5 54 current git, r300 115 146 pool_heap.patch, r300 17 119 process_heap.patch, r300 17 260 insert_first.patch, r300 27 167 insert_first is the patch from Eric Pouech. r300 means with the debug version of Mesas r300_dri.so, which has a total compilation unit size of around 9.2M (compared to the second biggest Wines user32 with 1.1M). Conclusions: - current git wins with small debug files (<2M or so), pool_heap wins with bigger files. insert_first, process_heap are out. - small pools have less memory overhead than small heaps - big pools have more memory overhead than big heaps. - big pools are a lot slower than big heaps. IMO the best results would give removing the pools (like in process_heap) and freeing unused memory manually, the other way round it was allocated. But at a first glance it looks like quite a bit of work, which I'm not sure is worth the result. I think the best approach would be to code some destroy functions in storage.c which would free the allocated vector, sparse_array and hash_table memory. And then gradually replace pool_alloc calls with HeapAlloc/HeapFree pairs. Markus

May 1, 2007

Re: Any way to get the current code besides git?

by EA Durbin

If you use the cvs web browser interface and view for example the dll msi and sort by age you will see the recent patches that have been applied show up here with the time they were applied. It is currently showing ones applied 8 hours ago. >From: sol11x86(a)comcast.net (Ben Taylor) >To: "EA Durbin" <ead1234(a)hotmail.com> >Subject: Re: Any way to get the current code besides git? >Date: Tue, 01 May 2007 20:39:04 +0000 > > -------------- Original message ---------------------- >From: "EA Durbin" <ead1234(a)hotmail.com> > > I had issues with older versions of git. > > > > I think cvs still works. > > > > http://winehq.org/site/cvs > >Yeah, but I'm not sure it's really current. It seemed to me >that the CVS code was just what was in the current release, >not what is current in git. I know because some patches I >had submitted and accepted to git weren't in the CVS download. > >Ben _________________________________________________________________ Interest Rates NEAR 39yr LOWS! $430,000 Mortgage for $1,299/mo - Calculate new payment http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-19132&moid=14888

May 1, 2007

Re: Any way to get the current code besides git?

by EA Durbin

I had issues with older versions of git. I think cvs still works. http://winehq.org/site/cvs _________________________________________________________________ Mortgage rates near historic lows. Refinance $200,000 loan for as low as $771/month* https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&searc…

May 1, 2007

Re: Any way to get the current code besides git?

by Alexandre Julliard

"Tom Spear" <speeddymon(a)gmail.com> writes: > Haven't killed it yet and been waiting for 2 hours.. I'm on a T-3 > afaik. Last line that prints before it just sits is: > > walk 4eea356e2d39f1a958afb4d8f5b54381e8972ecf That's precisely the last object before the big pack. Note that the processing of the pack can take a long time too, not only the download. You may want to upgrade your git version, there have been improvements in that area. Also if possible, using the git protocol instead of http is much faster. -- Alexandre Julliard julliard(a)winehq.org

May 1, 2007

Re: Any way to get the current code besides git?

by Tom Spear

On 5/1/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > "Tom Spear" <speeddymon(a)gmail.com> writes: > > > I'm having an issue using git at work, where it will start downloading > > the packs, and then just stalls out at the same pack every time.. > > This has occurred since I first started working here > > One of the packs is pretty large, most likely you didn't wait long > enough. Haven't killed it yet and been waiting for 2 hours.. I'm on a T-3 afaik. Last line that prints before it just sits is: walk 4eea356e2d39f1a958afb4d8f5b54381e8972ecf Just to dispel any idea that there is a size limit, I can download the entire dvd iso of Slackware 11 in about 20 minutes, with no problems, but that is from an http/ftp server. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 1, 2007

Re: Any way to get the current code besides git?

by Alexandre Julliard

"Tom Spear" <speeddymon(a)gmail.com> writes: > I'm having an issue using git at work, where it will start downloading > the packs, and then just stalls out at the same pack every time.. > This has occurred since I first started working here One of the packs is pretty large, most likely you didn't wait long enough. -- Alexandre Julliard julliard(a)winehq.org

May 1, 2007

Re: [try2] gdi32 : Completes WidenPath Implementation

by Alexandre Julliard

Laurent Vromman <laurent(a)vromman.org> writes: > I have sent this patch last week with the correction Alexandre asked > me to do. It is still not on the repository. > > Is there anything wrong again ? Any comments are welcomed and will be > applied if necessary. You didn't fix the memory leaks I mentioned. -- Alexandre Julliard julliard(a)winehq.org

May 1, 2007

Re: Fw: [PATCH] CMD.exe: Remove code duplication for _splitpath

by Alexandre Julliard

"Ann & Jason Edmeades" <us(a)edmeades.me.uk> writes: > Well, I am trying to convert cmd.exe to unicode, and was hoping to use the > wide crt functions to replace e.g. strstr, strdup etc. This way it's a > relatively simple transition from char to WCHAR without having to rewrite > other functions. LstrcatW and lstrcpyW help, but there's other functions > with no non-CRT equivalents. > > Does this change your mind? :-) It depends on how many there are, but in general I think using the Unicode functions from libwine is less confusing than the wcs* ones since we are not using a real wchar_t. -- Alexandre Julliard julliard(a)winehq.org

May 1, 2007

Re: http access ot GIT?

by sol11x86＠comcast.net

-------------- Original message ---------------------- From: "H. Verbeet" <hverbeet(a)gmail.com> > On 01/05/07, Tom Spear <speeddymon(a)gmail.com> wrote: > > Did you try changing the git:// to http:// ? That is supposed to > > work thru port 80 with or without squid. YMMV > > > IIRC you need to set the http_proxy env. var correctly as well. > Yep. needed to update the remote.origin.url and then setup the http_proxy env variable, and it all worked. Ben

May 1, 2007

Any way to get the current code besides git?

by Tom Spear

I'm having an issue using git at work, where it will start downloading the packs, and then just stalls out at the same pack every time.. This has occurred since I first started working here Maybe someone knows the problem, and a solution? If not, is there a way to get git to show file names instead of md5 sums, like cvs did, back when we used it, so I can at least know what file is causing the problem? If there is no solution, then maybe someone does know where I can get current code aside from git? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 1, 2007

Re: http access ot GIT?

by H. Verbeet

On 01/05/07, Tom Spear <speeddymon(a)gmail.com> wrote: > Did you try changing the git:// to http:// ? That is supposed to > work thru port 80 with or without squid. YMMV > IIRC you need to set the http_proxy env. var correctly as well.

May 1, 2007

Re: Direct3D viewport problems

by Stefan Dösinger

Am Dienstag 01 Mai 2007 13:17 schrieb H. Verbeet: > On 01/05/07, Robert Fairlie <rfairlie(a)kylebank.com> wrote: > > Since iSize is only about a fifth of the window height, I would expect > > the arrow to be displayed at the bottom left of the window. but it's > > actually being displayed at the top left. The main part of the scene > > rendered with the first viewport settings is fine. > > > > The code does as expected in Windows, so I was wondering if anyone knows > > of any problems in this area. I'm also having problems with CD3DFont > > which I think might be related to this. > > Direct3D coordinates are flipped compared to GL coordinates, so it > certainly sounds like a something that could go wrong. You didn't > explicitly mention if you are rendering offscreen with the second > viewport as well, but I'm assuming you are. I corrected a number of problems with the viewport setup some time ago for shadow rendering in Half-Life 2 and Final Fantasy XI, but the shadows in hl2 aren't perfect yet, so I suspect some remaining problems. To narrow the issue down I need some more information: Are you using a vertex shader or not? Are you using pretransformed geometry? (D3DFVF_XYZRHW, or the equivalent vertex declaration flag). Are you using vertex blend weights? Those parameters affect the way the opengl transforms and the viewport is set up. A test case would be useful, we could commit it to our wine test suit to avoid regressions once the problem is fixed. Otherwise I want to get detailed shadows in half-life 2 working properly soon, if you're lucky that fixes your bug too.

May 1, 2007

Re: http access ot GIT?

by Tom Spear

On 5/1/07, Ben Taylor <sol11x86(a)comcast.net> wrote: > > -------------- Original message ---------------------- > From: "Tom Spear" <speeddymon(a)gmail.com> > > On 5/1/07, Ben Taylor <sol11x86(a)comcast.net> wrote: > > > > > > Found myself behind an http-proxy and can't seem to find the magic > > > to use the http proxy to update my git archive. Is there a way to use > > > an http proxy (squid) with wine's git? > > > > What error are you getting? If no error, then if you to try to clone > > the whole repository, does it get to a point and then just sit there? > > > fatal: Unable to look up source.winehq.org (port 9418) (Name or service not konwn) > Cannot get the repository state from git://source.winehq.org/git/wine.git > > I've setup an http_proxy according to the documentation I've found on the > web. There's just not a lot out there that is specific to this conifguration. Did you try changing the git:// to http:// ? That is supposed to work thru port 80 with or without squid. YMMV -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 1, 2007

Compiling 32bit winelib apps on x86_64

by Stefan Brüns

Hi, I had some problems compiling 32bit winelib apps on x86_64 - the tools tried to build for 64bit all the time. I had to change a few things in the winemaker created Makefile to make it work: <>_exe_LDFLAGS: added "-Wb,--as-cmd='as --32',--ld-cmd='ld -melf_i386'" CC: added "-m32" CXX: added "-m32" After applying the changes, everything worked as expected. Greetings, Stefan -- Stefan Brüns / Kastanienweg 6 - Zimmer 1206 / 52074 Aachen mailto:lurch(a)gmx.li http://www.kawo1.rwth-aachen.de/~lurchi/ phone: +49 241 169-4206 mobile: +49 160 3797725

May 1, 2007

Re: Winscard support (for smart cards)

by Eric Pouech

Mounir IDRASSI a écrit : > Hi, > Please find attached the patch for adding header files for the support > of smart cards through Winscard dll. > If it's OK, should I post it elsewhere? > Thanks in advance. > > yes to wine-patches(a)winehq.com A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 1, 2007

Re: Winscard support (for smart cards)

by Mounir IDRASSI

Hi, Please find attached the patch for adding header files for the support of smart cards through Winscard dll. If it's OK, should I post it elsewhere? Thanks in advance. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > > sorry, I didn't actually compare the files, just saw the comments (my > bad) > that'll be better for the first patch not to include those C files > go ahead ;-) > A+ > >From 90fb2bc92327fc839d6a0ef68c3157035cd50c65 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Tue, 1 May 2007 18:03:01 +0200 Subject: Header files for the support of smart cards using Winscard dll --- include/Makefile.in | 3 + include/scarderr.h | 70 +++++++++ include/winscard.h | 416 +++++++++++++++++++++++++++++++++++++++++++++++++++ include/winsmcrd.h | 190 +++++++++++++++++++++++ 4 files changed, 679 insertions(+), 0 deletions(-) diff --git a/include/Makefile.in b/include/Makefile.in index 2577872..7dc0cc3 100644 --- a/include/Makefile.in +++ b/include/Makefile.in @@ -293,6 +293,7 @@ SRCDIR_INCLUDES = \ rpcndr.h \ rpcnterr.h \ rpcproxy.h \ + scarderr.h \ schannel.h \ schemadef.h \ schnlsp.h \ @@ -351,6 +352,8 @@ SRCDIR_INCLUDES = \ winreg.h \ winres.h \ winresrc.h \ + winscard.h \ + winsmcrd.h \ winsock.h \ winsock2.h \ winspool.h \ diff --git a/include/scarderr.h b/include/scarderr.h new file mode 100755 index 0000000..c07833e --- /dev/null +++ b/include/scarderr.h @@ -0,0 +1,70 @@ +/* + * 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 + */ + + +#ifndef _WINE_SCARDERR_H +#define _WINE_SCARDERR_H + + +#define SCARD_S_SUCCESS 0x00000000 +#define SCARD_F_INTERNAL_ERROR 0x80100001 /* An internal error occured while executing the operation */ +#define SCARD_E_CANCELLED 0x80100002 /* SCardCancel was called to cancel the operation */ +#define SCARD_E_INVALID_HANDLE 0x80100003 /* The given handle is not valid */ +#define SCARD_E_INVALID_PARAMETER 0x80100004 /* An invalid parameter was given in input*/ +#define SCARD_E_INVALID_TARGET 0x80100005 /* Smart card service encountered inconsistent installation information */ +#define SCARD_E_NO_MEMORY 0x80100006 /* No enough memory available to complete the operation */ +#define SCARD_F_WAITED_TOO_LONG 0x80100007 /* A timeout occured in an internal operation */ +#define SCARD_E_INSUFFICIENT_BUFFER 0x80100008 /* The output buffer is too small to receive data */ +#define SCARD_E_UNKNOWN_READER 0x80100009 /* The given reader name is unknwon to the system */ +#define SCARD_E_TIMEOUT 0x8010000A /* The operation timed out */ +#define SCARD_E_SHARING_VIOLATION 0x8010000B /* can't access the card because of other connections*/ + +#ifndef SCARD_E_NO_SMARTCARD +#define SCARD_E_NO_SMARTCARD 0x8010000C /* no smart card found on the reader*/ +#endif + +#define SCARD_E_UNKNOWN_CARD 0x8010000D /* The given card name is unknwon to the ssytem */ +#define SCARD_E_CANT_DISPOSE 0x8010000E /* The system can't handle the disposition request in SCardDisconnect or SCardEndTransaction*/ +#define SCARD_E_PROTO_MISMATCH 0x8010000F /* The given protocol is not compatible with the currenr card context */ +#define SCARD_E_NOT_READY 0x80100010 /* The reader or the card are not ready for use */ +#define SCARD_E_INVALID_VALUE 0x80100011 /* An invalid value was detected while */ +#define SCARD_E_SYSTEM_CANCELLED 0x80100012 /* The system canceld the current operation with the reader */ +#define SCARD_F_COMM_ERROR 0x80100013 /* A communication error occured with the reader */ +#define SCARD_F_UNKNOWN_ERROR 0x80100014 /* An unknown error occured */ +#define SCARD_E_INVALID_ATR 0x80100015 /* The ATR value is invalid */ +#define SCARD_E_NOT_TRANSACTED 0x80100016 /* no transaction exists */ +#define SCARD_E_READER_UNAVAILABLE 0x80100017 /* The reader is unavailable for use by the system, e.g. removed */ + +#define SCARD_E_PCI_TOO_SMALL 0x80100019 /* The PCI request receive buffer is too small*/ +#define SCARD_E_READER_UNSUPPORTED 0x8010001A /* The reader is unsupported due to the lack of capabilities*/ +#define SCARD_E_DUPLICATE_READER 0x8010001B /* more than one reader with the same name exist*/ +#define SCARD_E_CARD_UNSUPPORTED 0x8010001C /* The card inserted is not supported by the system */ +#define SCARD_E_NO_SERVICE 0x8010001D /* The Smart card resource manager is not running */ +#define SCARD_E_SERVICE_STOPPED 0x8010001E /* The Smart card resource manager has been stopped */ + +#define SCARD_E_NO_READERS_AVAILABLE 0x8010002E /* no reader found on the system */ + +#define SCARD_W_UNSUPPORTED_CARD 0x80100065 /* the card is unsupported and the reader can't communicate with it*/ +#define SCARD_W_UNRESPONSIVE_CARD 0x80100066 /* the card didn't send answer to the reset*/ +#define SCARD_W_UNPOWERED_CARD 0x80100067 /* the card is unpowered and the reader can't communicate with it*/ +#define SCARD_W_RESET_CARD 0x80100068 /* the card has been reset and any held information are invalid*/ +#define SCARD_W_REMOVED_CARD 0x80100069 /* the card has been removed from the reader*/ + + + +#endif diff --git a/include/winscard.h b/include/winscard.h new file mode 100755 index 0000000..f302a9f --- /dev/null +++ b/include/winscard.h @@ -0,0 +1,416 @@ +/* + * 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 + */ + + + +#ifndef _WINE_WINSCARD_H +#define _WINE_WINSCARD_H + +#include "winsmcrd.h" +#include "scarderr.h" + +/* + * these variables store pre-filled protocol requests + */ +extern SCARD_IO_REQUEST g_rgSCardT0Pci; +extern SCARD_IO_REQUEST g_rgSCardT1Pci; +extern SCARD_IO_REQUEST g_rgSCardRawPci; + +/* + * These are handy shotcuts to be used in SCardTransmit + * They are implemented here as pointer variables + */ + extern SCARD_IO_REQUEST* SCARD_PCI_T0; /* equal to (&g_rgSCardT0Pci) */ + extern SCARD_IO_REQUEST* SCARD_PCI_T1; /* equal to (&g_rgSCardT1Pci) */ + extern SCARD_IO_REQUEST* SCARD_PCI_RAW; /* equal to (&g_rgSCardRawPci) */ + + +#ifdef __cplusplus +extern "C" { +#endif + + +/* + * Smart Card service manager function + */ + +LONG WINAPI SCardEstablishContext( + DWORD dwScope, + LPCVOID pvReserved1, + LPCVOID pvReserved2, + LPSCARDCONTEXT phContext); + +LONG WINAPI SCardReleaseContext( + SCARDCONTEXT hContext); + +LONG WINAPI SCardFreeMemory( + SCARDCONTEXT hContext, + LPCVOID pvMem); + +HANDLE WINAPI SCardAccessStartedEvent(void); + +void WINAPI SCardReleaseStartedEvent( + HANDLE hStartedEventHandle); + +LONG WINAPI SCardIsValidContext( + SCARDCONTEXT hContext); + + +/* + * Smart Card database functions + */ + +LONG WINAPI SCardListReaderGroupsA( + SCARDCONTEXT hContext, + LPSTR mszGroups, + LPDWORD pcchGroups); +LONG WINAPI SCardListReaderGroupsW( + SCARDCONTEXT hContext, + LPWSTR mszGroups, + LPDWORD pcchGroups); + +#define SCardListReaderGroups WINELIB_NAME_AW(SCardListReaderGroups) + + +LONG WINAPI SCardListReadersA( + SCARDCONTEXT hContext, + LPCSTR mszGroups, + LPSTR mszReaders, + LPDWORD pcchReaders); +LONG WINAPI SCardListReadersW( + SCARDCONTEXT hContext, + LPCWSTR mszGroups, + LPWSTR mszReaders, + LPDWORD pcchReaders); + +#define SCardListReaders WINELIB_NAME_AW(SCardListReaders) + +LONG WINAPI SCardListCardsA( + SCARDCONTEXT hContext, + const BYTE* pbAtr, + LPCGUID rgquidInterfaces, + DWORD cguidInterfaceCount, + LPSTR mszCards, + LPDWORD pcchCards); +LONG WINAPI SCardListCardsW( + SCARDCONTEXT hContext, + const BYTE* pbAtr, + LPCGUID rgquidInterfaces, + DWORD cguidInterfaceCount, + LPWSTR mszCards, + LPDWORD pcchCards); + +#define SCardListCards WINELIB_NAME_AW(SCardListCards) + +LONG WINAPI SCardListInterfacesA( + SCARDCONTEXT hContext, + LPCSTR szCard, + LPGUID pguidInterfaces, + LPDWORD pcguidInterfaces); +LONG WINAPI SCardListInterfacesW( + SCARDCONTEXT hContext, + LPCWSTR szCard, + LPGUID pguidInterfaces, + LPDWORD pcguidInterfaces); + +#define SCardListInterfaces WINELIB_NAME_AW(SCardListInterfaces) + +LONG WINAPI SCardGetProviderIdA( + SCARDCONTEXT hContext, + LPCSTR szCard, + LPGUID pguidProviderId); +LONG WINAPI SCardGetProviderIdW( + SCARDCONTEXT hContext, + LPCWSTR szCard, + LPGUID pguidProviderId); + +#define SCardGetProviderId WINELIB_NAME_AW(SCardGetProviderId) + +LONG WINAPI SCardGetCardTypeProviderNameA( + SCARDCONTEXT hContext, + LPCSTR szCardName, + DWORD dwProviderId, + LPSTR szProvider, + LPDWORD pcchProvider); +LONG WINAPI SCardGetCardTypeProviderNameW( + SCARDCONTEXT hContext, + LPCWSTR szCardName, + DWORD dwProviderId, + LPWSTR szProvider, + LPDWORD pcchProvider); + +#define SCardGetCardTypeProviderName WINELIB_NAME_AW(SCardGetCardTypeProviderName) + +LONG WINAPI SCardIntroduceReaderGroupA( + SCARDCONTEXT hContext, + LPCSTR szGroupName); +LONG WINAPI SCardIntroduceReaderGroupW( + SCARDCONTEXT hContext, + LPCWSTR szGroupName); + +#define SCardIntroduceReaderGroup WINELIB_NAME_AW(SCardIntroduceReaderGroup) + +LONG WINAPI SCardForgetReaderGroupA( + SCARDCONTEXT hContext, + LPCSTR szGroupName); +LONG WINAPI SCardForgetReaderGroupW( + SCARDCONTEXT hContext, + LPCWSTR szGroupName); + +#define SCardForgetReaderGroup WINELIB_NAME_AW(SCardForgetReaderGroup) + + +LONG WINAPI SCardIntroduceReaderA( + SCARDCONTEXT hContext, + LPCSTR szReaderName, + LPCSTR szDeviceName); +LONG WINAPI SCardIntroduceReaderW( + SCARDCONTEXT hContext, + LPCWSTR szReaderName, + LPCWSTR szDeviceName); + +#define SCardIntroduceReader WINELIB_NAME_AW(SCardIntroduceReader) + +LONG WINAPI SCardForgetReaderA( + SCARDCONTEXT hContext, + LPCSTR szReaderName); +LONG WINAPI SCardForgetReaderW( + SCARDCONTEXT hContext, + LPCWSTR szReaderName); + +#define SCardForgetReader WINELIB_NAME_AW(SCardForgetReader) + +LONG WINAPI SCardAddReaderToGroupA( + SCARDCONTEXT hContext, + LPCSTR szReaderName, + LPCSTR szGroupName); +LONG WINAPI SCardAddReaderToGroupW( + SCARDCONTEXT hContext, + LPCWSTR szReaderName, + LPCWSTR szGroupName); + +#define SCardAddReaderToGroup WINELIB_NAME_AW(SCardAddReaderToGroup) + +LONG WINAPI SCardRemoveReaderFromGroupA( + SCARDCONTEXT hContext, + LPCSTR szReaderName, + LPCSTR szGroupName); +LONG WINAPI SCardRemoveReaderFromGroupW( + SCARDCONTEXT hContext, + LPCWSTR szReaderName, + LPCWSTR szGroupName); + +#define SCardRemoveReaderFromGroup WINELIB_NAME_AW(SCardRemoveReaderFromGroup) + +LONG WINAPI SCardIntroduceCardTypeA( + SCARDCONTEXT hContext, + LPCSTR szCardName, + LPCGUID pguidPrimaryProvider, + LPCGUID rgguidInterfaces, + DWORD dwInterfaceCount, + const BYTE* pbAtr, + const BYTE* pbAtrMask, + DWORD cbAtrLen); +LONG WINAPI SCardIntroduceCardTypeW( + SCARDCONTEXT hContext, + LPCWSTR szCardName, + LPCGUID pguidPrimaryProvider, + LPCGUID rgguidInterfaces, + DWORD dwInterfaceCount, + const BYTE* pbAtr, + const BYTE* pbAtrMask, + DWORD cbAtrLen); + +#define SCardIntroduceCardType WINELIB_NAME_AW(SCardIntroduceCardType) + +LONG WINAPI SCardSetCardTypeProviderNameA( + SCARDCONTEXT hContext, + LPCSTR szCardName, + DWORD dwProviderId, + LPCSTR szProvider); +LONG WINAPI SCardSetCardTypeProviderNameW( + SCARDCONTEXT hContext, + LPCWSTR szCardName, + DWORD dwProviderId, + LPCWSTR szProvider); + +#define SCardSetCardTypeProviderName WINELIB_NAME_AW(SCardSetCardTypeProviderName) + +LONG WINAPI SCardForgetCardTypeA( + SCARDCONTEXT hContext, + LPCSTR szCardName); +LONG WINAPI SCardForgetCardTypeW( + SCARDCONTEXT hContext, + LPCWSTR szCardName); + +#define SCardForgetCardType WINELIB_NAME_AW(SCardForgetCardType) + +LONG WINAPI SCardLocateCardsA( + SCARDCONTEXT hContext, + LPCSTR mszCards, + LPSCARD_READERSTATEA rgReaderStates, + DWORD cReaders); +LONG WINAPI SCardLocateCardsW( + SCARDCONTEXT hContext, + LPCWSTR mszCards, + LPSCARD_READERSTATEW rgReaderStates, + DWORD cReaders); + +#define SCardLocateCards WINELIB_NAME_AW(SCardLocateCards) + +LONG WINAPI SCardLocateCardsByATRA( + SCARDCONTEXT hContext, + LPSCARD_ATRMASK rgAtrMasks, + DWORD cAtrs, + LPSCARD_READERSTATEA rgReaderStates, + DWORD cReaders); +LONG WINAPI SCardLocateCardsByATRW( + SCARDCONTEXT hContext, + LPSCARD_ATRMASK rgAtrMasks, + DWORD cAtrs, + LPSCARD_READERSTATEW rgReaderStates, + DWORD cReaders); + +#define SCardLocateCardsByATR WINELIB_NAME_AW(SCardLocateCardsByATR) + +/* + * Smart card communication functions + */ + +LONG WINAPI SCardConnectA( + SCARDCONTEXT hContext, + LPCSTR szReader, + DWORD dwShareMode, + DWORD dwPreferredProtocols, + LPSCARDHANDLE phCard, + LPDWORD pdwActiveProtocol); +LONG WINAPI SCardConnectW( + SCARDCONTEXT hContext, + LPCWSTR szReader, + DWORD dwShareMode, + DWORD dwPreferredProtocols, + LPSCARDHANDLE phCard, + LPDWORD pdwActiveProtocol); + +#define SCardConnect WINELIB_NAME_AW(SCardConnect) + +LONG WINAPI SCardReconnect( + SCARDHANDLE hCard, + DWORD dwShareMode, + DWORD dwPreferredProtocols, + DWORD dwInitialization, + LPDWORD pdwActiveProtocol); + +LONG WINAPI SCardDisconnect( + SCARDHANDLE hCard, + DWORD dwDisposition); + +LONG WINAPI SCardBeginTransaction( + SCARDHANDLE hCard); + +LONG WINAPI SCardEndTransaction( + SCARDHANDLE hCard, + DWORD dwDisposition); + +LONG WINAPI SCardCancelTransaction( + SCARDHANDLE hCard); + +LONG WINAPI SCardControl( + SCARDHANDLE hCard, + DWORD dwControlCode, + LPCVOID pbSendBuffer, + DWORD cbSendLength, + LPVOID pbRecvBuffer, + DWORD cbRecvLength, + LPDWORD lpBytesReturned); + +LONG WINAPI SCardTransmit( + SCARDHANDLE hCard, + LPCSCARD_IO_REQUEST pioSendPci, + const BYTE* pbSendBuffer, + DWORD cbSendLength, + LPSCARD_IO_REQUEST pioRecvPci, + LPBYTE pbRecvBuffer, + LPDWORD pcbRecvLength); + +LONG WINAPI SCardCancel( + SCARDCONTEXT hContext); + + +/* + * Smart card tracking functions + */ + +LONG WINAPI SCardState( + SCARDHANDLE hCard, + LPDWORD pdwState, + LPDWORD pdwProtocol, + LPBYTE pbAtr, + LPDWORD pcbAtrLen); + +LONG WINAPI SCardStatusA( + SCARDHANDLE hCard, + LPSTR mszReaderNames, + LPDWORD pcchReaderLen, + LPDWORD pdwState, + LPDWORD pdwProtocol, + LPBYTE pbAtr, + LPDWORD pcbAtrLen); +LONG WINAPI SCardStatusW( + SCARDHANDLE hCard, + LPWSTR mszReaderNames, + LPDWORD pcchReaderLen, + LPDWORD pdwState, + LPDWORD pdwProtocol, + LPBYTE pbAtr, + LPDWORD pcbAtrLen); + +#define SCardStatus WINELIB_NAME_AW(SCardStatus) + +LONG WINAPI SCardGetStatusChangeA( + SCARDCONTEXT hContext, + DWORD dwTimeout, + LPSCARD_READERSTATEA rgReaderStates, + DWORD cReaders); +LONG WINAPI SCardGetStatusChangeW( + SCARDCONTEXT hContext, + DWORD dwTimeout, + LPSCARD_READERSTATEW rgReaderStates, + DWORD cReaders); + +#define SCardGetStatusChange WINELIB_NAME_AW(SCardGetStatusChange) + +LONG WINAPI SCardGetAttrib( + SCARDHANDLE hCard, + DWORD dwAttrId, + LPBYTE pbAttr, + LPDWORD pcbAttrLen); + +LONG WINAPI SCardSetAttrib( + SCARDHANDLE hCard, + DWORD dwAttrId, + const BYTE* pbAttr, + DWORD cbAttrLen); + + +#ifdef __cplusplus +} +#endif + +#endif + diff --git a/include/winsmcrd.h b/include/winsmcrd.h new file mode 100755 index 0000000..cc03a35 --- /dev/null +++ b/include/winsmcrd.h @@ -0,0 +1,190 @@ +/* + * 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 + */ + + +#ifndef _WINE_WINSCMCRD_H +#define _WINE_WINSCMCRD_H + + +#define MAX_ATR_SIZE 36 /* Maximum ATR size */ + +#ifndef SCARD_ATR_LENGTH +#define SCARD_ATR_LENGTH MAX_ATR_SIZE +#endif + +/* + * These values define the protocol used to + * communicate with the card + */ +#define SCARD_PROTOCOL_UNDEFINED 0x00000000 /* No protocol defined */ +#define SCARD_PROTOCOL_T0 0x00000001 /* T=0 protocol. */ +#define SCARD_PROTOCOL_T1 0x00000002 /* T=1 protocol */ +#define SCARD_PROTOCOL_RAW 0x00010000 /* Raw protocol, for memory card for example */ +#define SCARD_PROTOCOL_Tx (SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1) /* Can be used in SCardConnect */ + +/* + * The following value is used as a length value + * in functions where we want the winscard dll + * to allocate memory for us + */ +#define SCARD_AUTOALLOCATE (DWORD)(-1) + +/* + * Values used by SCardEstablishContext + */ +#define SCARD_SCOPE_USER 0x0000 /* context in user scope */ +#define SCARD_SCOPE_TERMINAL 0x0001 /* context in terminal scope */ +#define SCARD_SCOPE_SYSTEM 0x0002 /* context in system scope */ + +/* + * Flags used by SCardGetStatusChange to indicate + * the reader status. + */ +#define SCARD_STATE_UNAWARE 0x0000 /* called want to know the current state */ +#define SCARD_STATE_IGNORE 0x0001 /* don't update the state for the given reader */ +#define SCARD_STATE_CHANGED 0x0002 /* reader state has not changed */ +#define SCARD_STATE_UNKNOWN 0x0004 /* reader state unknown */ +#define SCARD_STATE_UNAVAILABLE 0x0008 /* reader state unavailable */ +#define SCARD_STATE_EMPTY 0x0010 /* no card on the reader*/ +#define SCARD_STATE_PRESENT 0x0020 /* card present on the reader */ +#define SCARD_STATE_ATRMATCH 0x0040 /* card's ATR matches the given ATR */ +#define SCARD_STATE_EXCLUSIVE 0x0080 /* an exclusive connection on the card exists*/ +#define SCARD_STATE_INUSE 0x0100 /* card in use but the connection can be shared */ +#define SCARD_STATE_MUTE 0x0200 /* card is mute, doesn't answer to reset */ +#define SCARD_STATE_UNPOWERED 0x0400 /* card present but not powered */ + + +/* + * These values define how SCardConnect should + * connect to the card + */ +#define SCARD_SHARE_EXCLUSIVE 0x0001 /* connect to the card in exclusive mode (no other connection allowed) */ +#define SCARD_SHARE_SHARED 0x0002 /* connection can be shared with others */ +#define SCARD_SHARE_DIRECT 0x0003 /* access directly the reader, no other connection allowed */ + +/* + * Values used by SCardDisconnect to specify + * how the card should be treated on closing + * the connection + */ +#define SCARD_LEAVE_CARD 0x0000 /* do nothing */ +#define SCARD_RESET_CARD 0x0001 /* reset the card */ +#define SCARD_UNPOWER_CARD 0x0002 /* unpower the card */ +#define SCARD_EJECT_CARD 0x0003 /* eject the card from the reader if supported */ + +/* + * Values returned by SCardStatus indicating + * the reader's state + */ +#define SCARD_UNKNOWN 0x0001 /* state unknown */ +#define SCARD_ABSENT 0x0002 /* no card on the reader */ +#define SCARD_PRESENT 0x0004 /* card is present on the reader */ +#define SCARD_SWALLOWED 0x0008 /* card inside the reader but not powered */ +#define SCARD_POWERED 0x0010 /* card present and powered */ +#define SCARD_NEGOTIABLE 0x0020 /* card present and ready to negotiate protocol */ +#define SCARD_SPECIFIC 0x0040 /* card has ended protocol negotiation */ + +/* + * definitions used by SCardGetAttrib and SCardSetAttrib for + * requesting and setting readers attributes + * Other values maybe supported + */ +#define SCARD_ATTR_ICC_PRESENCE 0x00090300 +#define SCARD_ATTR_CURRENT_PROTOCOL_TYPE 0x00080201 +#define SCARD_ATTR_ATR_STRING 0x00090303 +#define SCARD_ATTR_DEVICE_FRIENDLY_NAME_A 0x7FFF0003 +#define SCARD_ATTR_DEVICE_FRIENDLY_NAME_W 0x7FFF0005 +#define SCARD_ATTR_DEVICE_SYSTEM_NAME_A 0x7FFF0004 +#define SCARD_ATTR_DEVICE_SYSTEM_NAME_W 0x7FFF0006 + +#define SCARD_ATTR_DEVICE_FRIENDLY_NAME WINELIB_NAME_AW(SCARD_ATTR_DEVICE_FRIENDLY_NAME_) +#define SCARD_ATTR_DEVICE_SYSTEM_NAME WINELIB_NAME_AW(SCARD_ATTR_DEVICE_SYSTEM_NAME_) + +/* + * Type definitions used by all the functions + */ +typedef ULONG_PTR SCARDCONTEXT; +typedef SCARDCONTEXT *PSCARDCONTEXT; +typedef SCARDCONTEXT *LPSCARDCONTEXT; + +typedef ULONG_PTR SCARDHANDLE; +typedef SCARDHANDLE *PSCARDHANDLE; +typedef SCARDHANDLE *LPSCARDHANDLE; + + +/* + * SCARD_READERSTATE is used by SCardGetStatusChange as an + * input/output for any change of readers states + */ +typedef struct +{ + LPCSTR szReader; + void *pvUserData; + unsigned long dwCurrentState; + unsigned long dwEventState; + unsigned long cbAtr; + unsigned char rgbAtr[MAX_ATR_SIZE]; +} +SCARD_READERSTATEA; + +typedef struct +{ + LPCWSTR szReader; + void *pvUserData; + unsigned long dwCurrentState; + unsigned long dwEventState; + unsigned long cbAtr; + unsigned char rgbAtr[MAX_ATR_SIZE]; +} +SCARD_READERSTATEW; + +typedef SCARD_READERSTATEA *PSCARD_READERSTATEA, *LPSCARD_READERSTATEA; + +typedef SCARD_READERSTATEW *PSCARD_READERSTATEW, *LPSCARD_READERSTATEW; + +DECL_WINELIB_TYPE_AW(SCARD_READERSTATE) +DECL_WINELIB_TYPE_AW(PSCARD_READERSTATE) +DECL_WINELIB_TYPE_AW(LPSCARD_READERSTATE) + +/* + * This structure is used by SCardTransmit to communicate + * with the card + */ +typedef struct _SCARD_IO_REQUEST +{ + unsigned long dwProtocol; /* protocol used for this request */ + unsigned long cbPciLength; /* total length of the request data, usually sizeof(SCARD_IO_REQUEST) */ +} +SCARD_IO_REQUEST, *PSCARD_IO_REQUEST, *LPSCARD_IO_REQUEST; + +typedef const SCARD_IO_REQUEST *LPCSCARD_IO_REQUEST; + +/* + * This structure is used by the new functions + * SCardLocateCardsByATRA and SCardLocateCardsByATRW + */ +typedef struct _SCARD_ATRMASK { + unsigned long cbAtr; /* number of used bytes in rgbAtr and rgbMask*/ + unsigned char rgbAtr[MAX_ATR_SIZE]; /* ATR bytes of the card */ + unsigned char rgbMask[MAX_ATR_SIZE]; /* Mask used for accepted ATR values */ +} SCARD_ATRMASK; + +typedef SCARD_ATRMASK *PSCARD_ATRMASK, *LPSCARD_ATRMASK; + +#endif + -- 1.4.4.2

May 1, 2007

Re: Winscard support (for smart cards)

by Eric Pouech

Mounir IDRASSI a écrit : > Hi Eric, > I am afraid I don't see any MS comments in scarderr.h: I have written > all the file from scratch and the comments are mine. Can you point them > out please? > sorry, I didn't actually compare the files, just saw the comments (my bad) > In the final implementation, all the functions are needed even if they > are stubs because they can be called by applications that ignore them if > they report an error. That's why we must implement them all. But I can > start with stubs in the spec file for the first patch. > that'll be better for the first patch not to include those C files > I'll wait for your reply before submitting the first patch. > Thanks. > go ahead ;-) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 1, 2007

Re: http access ot GIT?

by Tom Spear

On 5/1/07, Ben Taylor <sol11x86(a)comcast.net> wrote: > > Found myself behind an http-proxy and can't seem to find the magic > to use the http proxy to update my git archive. Is there a way to use > an http proxy (squid) with wine's git? What error are you getting? If no error, then if you to try to clone the whole repository, does it get to a point and then just sit there? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 1, 2007

Re: Winscard support (for smart cards)

by Mounir IDRASSI

Hi Eric, I am afraid I don't see any MS comments in scarderr.h: I have written all the file from scratch and the comments are mine. Can you point them out please? In the final implementation, all the functions are needed even if they are stubs because they can be called by applications that ignore them if they report an error. That's why we must implement them all. But I can start with stubs in the spec file for the first patch. I'll wait for your reply before submitting the first patch. Thanks. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > thanks for your work > > I still have a couple of comments: > - you don't need at first (for the skeletton) to provide an empty > implementation for a given function. If you use the stub keyword in > the .spec file, Wine will create a minimal stub for the function > (that'll make the program crash when it's called), but is sufficient > when the API is never called => this is the preferred way to go. All > your stubs are not lost, you'll reuse them when providing the first > API implementation > - basically, I'd submit a patch for the headers and a second one for > the skeletton of the DLL. Then you can go on with the various API > implementations > > From the coding itself: > - in traces, don't cast handles to int, it won't work every where... > rather use "%x", handle => that's portable > - there's still (void) functions declared as () (in the C files) > - there's still MS comments in scarderr.h > > A+ >

May 1, 2007

Re: Winscard support (for smart cards)

by Eric Pouech

Mounir IDRASSI a écrit : > Hi all, > Followings your comments, I have rewritten the header files and split > winscard.c into smaller files. > You'll find attached with this email a patch containing only the headers > and a skeleton for this dll. > Once integrated into the source tree, I'll provide another patch (or > patches) containing the rest of the implementation. > I hope th thanks for your work I still have a couple of comments: - you don't need at first (for the skeletton) to provide an empty implementation for a given function. If you use the stub keyword in the .spec file, Wine will create a minimal stub for the function (that'll make the program crash when it's called), but is sufficient when the API is never called => this is the preferred way to go. All your stubs are not lost, you'll reuse them when providing the first API implementation - basically, I'd submit a patch for the headers and a second one for the skeletton of the DLL. Then you can go on with the various API implementations From the coding itself: - in traces, don't cast handles to int, it won't work every where... rather use "%x", handle => that's portable - there's still (void) functions declared as () (in the C files) - there's still MS comments in scarderr.h A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 1, 2007

http access ot GIT?

by sol11x86＠comcast.net

Found myself behind an http-proxy and can't seem to find the magic to use the http proxy to update my git archive. Is there a way to use an http proxy (squid) with wine's git? Ben

May 1, 2007

Re: Winscard support (for smart cards)

by Mounir IDRASSI

Hi all, Followings your comments, I have rewritten the header files and split winscard.c into smaller files. You'll find attached with this email a patch containing only the headers and a skeleton for this dll. Once integrated into the source tree, I'll provide another patch (or patches) containing the rest of the implementation. I hope this time I did it right. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr >From c9e8ffa28e3f100bd9e696c3a287a75bd366ccd0 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Tue, 1 May 2007 15:48:25 +0200 Subject: Headers and skeleton of the wine Winscard dll --- 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 | 147 +++++++++++++++ dlls/winscard/scarddb.c | 390 ++++++++++++++++++++++++++++++++++++++ dlls/winscard/scardtracking.c | 124 ++++++++++++ dlls/winscard/winscard.c | 116 ++++++++++++ dlls/winscard/winscard.spec | 66 +++++++ include/Makefile.in | 3 + include/scarderr.h | 70 +++++++ include/winscard.h | 416 +++++++++++++++++++++++++++++++++++++++++ include/winsmcrd.h | 190 +++++++++++++++++++ 15 files changed, 1586 insertions(+), 0 deletions(-) diff --git a/Makefile.in b/Makefile.in index 1f8f0c9..fd825a7 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 \ @@ -762,6 +763,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 71a66ae..1a11b08 100755 --- a/configure +++ b/configure @@ -20839,6 +20839,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" @@ -21806,6 +21808,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 ddec5f4..19026c6 100644 --- a/configure.ac +++ b/configure.ac @@ -1744,6 +1744,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 100755 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..1a3f637 --- /dev/null +++ b/dlls/winscard/scardcomm.c @@ -0,0 +1,147 @@ +/* + * 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 "wine/debug.h" +#include "wine/library.h" +#include "wine/unicode.h" +#include <winscard.h> + +WINE_DEFAULT_DEBUG_CHANNEL(winscard); + +LONG WINAPI SCardEstablishContext(DWORD dwScope,LPCVOID pvReserved1, LPCVOID pvReserved2, LPSCARDCONTEXT phContext) +{ + FIXME(" 0x%08X %p %p %p\n",dwScope,pvReserved1,pvReserved2,phContext); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + + +LONG WINAPI SCardReleaseContext(SCARDCONTEXT hContext) +{ + FIXME(" 0x%08X\n", (unsigned int) hContext); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardIsValidContext(SCARDCONTEXT hContext) +{ + FIXME(" 0x%08X\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\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\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\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\n",(unsigned int) hCard,dwDisposition); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardBeginTransaction(SCARDHANDLE hCard) +{ + FIXME(" 0x%08X\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\n",(unsigned int) hCard,dwDisposition); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return SCARD_F_UNKNOWN_ERROR; +} + +LONG WINAPI SCardCancelTransaction(SCARDHANDLE hCard) +{ + FIXME(" 0x%08X\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, + const BYTE* 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..4bc31ff --- /dev/null +++ b/dlls/winscard/scarddb.c @@ -0,0 +1,390 @@ +/* + * 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 "wine/debug.h" +#include "wine/library.h" +#include "wine/unicode.h" +#include <winscard.h> + +WINE_DEFAULT_DEBUG_CHANNEL(winscard); + +/* + * smar 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, + const BYTE* 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, + const BYTE* 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, + const BYTE* pbAtr, + const BYTE* 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, + const BYTE* pbAtr, + const BYTE* 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..ede697e --- /dev/null +++ b/dlls/winscard/scardtracking.c @@ -0,0 +1,124 @@ +/* + * 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 "wine/debug.h" +#include "wine/library.h" +#include "wine/unicode.h" +#include <winscard.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\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\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\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\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\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 \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 \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 \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 100755 index 0000000..30186f4 --- /dev/null +++ b/dlls/winscard/winscard.c @@ -0,0 +1,116 @@ +/* + * 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 "wine/debug.h" +#include "wine/library.h" +#include "wine/unicode.h" +#include <winscard.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; +} + + +/* + * events 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(HANDLE hStartedEventHandle) +{ + FIXME("0x%08X - stub\n",(unsigned int) hStartedEventHandle); +} + + +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 100755 index 0000000..f636d46 --- /dev/null +++ b/dlls/winscard/winscard.spec @@ -0,0 +1,66 @@ +@ stub ClassInstall32 +@ stdcall SCardAccessNewReaderEvent() +@ stdcall SCardReleaseAllEvents() +@ stdcall SCardReleaseNewReaderEvent() +@ 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 SCardForgetReaderGroupA(long str) +@ stdcall SCardForgetReaderGroupW(long wstr) +@ stdcall SCardForgetReaderW(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 SCardIntroduceReaderGroupA(long str) +@ stdcall SCardIntroduceReaderGroupW(long wstr) +@ stdcall SCardIntroduceReaderW(long wstr 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 SCardListReaderGroupsA(long str ptr) +@ stdcall SCardListReaderGroupsW(long wstr ptr) +@ stdcall SCardListReadersA(long str str ptr) +@ stdcall SCardListReadersW(long wstr wstr ptr) +@ stdcall SCardLocateCardsA(long str ptr long) +@ stdcall SCardLocateCardsByATRA(long ptr long ptr long) +@ stdcall SCardLocateCardsByATRW(long ptr long ptr long) +@ stdcall SCardLocateCardsW(long wstr ptr long) +@ stdcall SCardReconnect(long long long long ptr) +@ stdcall SCardReleaseContext(long) +@ 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 diff --git a/include/Makefile.in b/include/Makefile.in index 2577872..7dc0cc3 100644 --- a/include/Makefile.in +++ b/include/Makefile.in @@ -293,6 +293,7 @@ SRCDIR_INCLUDES = \ rpcndr.h \ rpcnterr.h \ rpcproxy.h \ + scarderr.h \ schannel.h \ schemadef.h \ schnlsp.h \ @@ -351,6 +352,8 @@ SRCDIR_INCLUDES = \ winreg.h \ winres.h \ winresrc.h \ + winscard.h \ + winsmcrd.h \ winsock.h \ winsock2.h \ winspool.h \ diff --git a/include/scarderr.h b/include/scarderr.h new file mode 100755 index 0000000..c07833e --- /dev/null +++ b/include/scarderr.h @@ -0,0 +1,70 @@ +/* + * 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 + */ + + +#ifndef _WINE_SCARDERR_H +#define _WINE_SCARDERR_H + + +#define SCARD_S_SUCCESS 0x00000000 +#define SCARD_F_INTERNAL_ERROR 0x80100001 /* An internal error occured while executing the operation */ +#define SCARD_E_CANCELLED 0x80100002 /* SCardCancel was called to cancel the operation */ +#define SCARD_E_INVALID_HANDLE 0x80100003 /* The given handle is not valid */ +#define SCARD_E_INVALID_PARAMETER 0x80100004 /* An invalid parameter was given in input*/ +#define SCARD_E_INVALID_TARGET 0x80100005 /* Smart card service encountered inconsistent installation information */ +#define SCARD_E_NO_MEMORY 0x80100006 /* No enough memory available to complete the operation */ +#define SCARD_F_WAITED_TOO_LONG 0x80100007 /* A timeout occured in an internal operation */ +#define SCARD_E_INSUFFICIENT_BUFFER 0x80100008 /* The output buffer is too small to receive data */ +#define SCARD_E_UNKNOWN_READER 0x80100009 /* The given reader name is unknwon to the system */ +#define SCARD_E_TIMEOUT 0x8010000A /* The operation timed out */ +#define SCARD_E_SHARING_VIOLATION 0x8010000B /* can't access the card because of other connections*/ + +#ifndef SCARD_E_NO_SMARTCARD +#define SCARD_E_NO_SMARTCARD 0x8010000C /* no smart card found on the reader*/ +#endif + +#define SCARD_E_UNKNOWN_CARD 0x8010000D /* The given card name is unknwon to the ssytem */ +#define SCARD_E_CANT_DISPOSE 0x8010000E /* The system can't handle the disposition request in SCardDisconnect or SCardEndTransaction*/ +#define SCARD_E_PROTO_MISMATCH 0x8010000F /* The given protocol is not compatible with the currenr card context */ +#define SCARD_E_NOT_READY 0x80100010 /* The reader or the card are not ready for use */ +#define SCARD_E_INVALID_VALUE 0x80100011 /* An invalid value was detected while */ +#define SCARD_E_SYSTEM_CANCELLED 0x80100012 /* The system canceld the current operation with the reader */ +#define SCARD_F_COMM_ERROR 0x80100013 /* A communication error occured with the reader */ +#define SCARD_F_UNKNOWN_ERROR 0x80100014 /* An unknown error occured */ +#define SCARD_E_INVALID_ATR 0x80100015 /* The ATR value is invalid */ +#define SCARD_E_NOT_TRANSACTED 0x80100016 /* no transaction exists */ +#define SCARD_E_READER_UNAVAILABLE 0x80100017 /* The reader is unavailable for use by the system, e.g. removed */ + +#define SCARD_E_PCI_TOO_SMALL 0x80100019 /* The PCI request receive buffer is too small*/ +#define SCARD_E_READER_UNSUPPORTED 0x8010001A /* The reader is unsupported due to the lack of capabilities*/ +#define SCARD_E_DUPLICATE_READER 0x8010001B /* more than one reader with the same name exist*/ +#define SCARD_E_CARD_UNSUPPORTED 0x8010001C /* The card inserted is not supported by the system */ +#define SCARD_E_NO_SERVICE 0x8010001D /* The Smart card resource manager is not running */ +#define SCARD_E_SERVICE_STOPPED 0x8010001E /* The Smart card resource manager has been stopped */ + +#define SCARD_E_NO_READERS_AVAILABLE 0x8010002E /* no reader found on the system */ + +#define SCARD_W_UNSUPPORTED_CARD 0x80100065 /* the card is unsupported and the reader can't communicate with it*/ +#define SCARD_W_UNRESPONSIVE_CARD 0x80100066 /* the card didn't send answer to the reset*/ +#define SCARD_W_UNPOWERED_CARD 0x80100067 /* the card is unpowered and the reader can't communicate with it*/ +#define SCARD_W_RESET_CARD 0x80100068 /* the card has been reset and any held information are invalid*/ +#define SCARD_W_REMOVED_CARD 0x80100069 /* the card has been removed from the reader*/ + + + +#endif diff --git a/include/winscard.h b/include/winscard.h new file mode 100755 index 0000000..f302a9f --- /dev/null +++ b/include/winscard.h @@ -0,0 +1,416 @@ +/* + * 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 + */ + + + +#ifndef _WINE_WINSCARD_H +#define _WINE_WINSCARD_H + +#include "winsmcrd.h" +#include "scarderr.h" + +/* + * these variables store pre-filled protocol requests + */ +extern SCARD_IO_REQUEST g_rgSCardT0Pci; +extern SCARD_IO_REQUEST g_rgSCardT1Pci; +extern SCARD_IO_REQUEST g_rgSCardRawPci; + +/* + * These are handy shotcuts to be used in SCardTransmit + * They are implemented here as pointer variables + */ + extern SCARD_IO_REQUEST* SCARD_PCI_T0; /* equal to (&g_rgSCardT0Pci) */ + extern SCARD_IO_REQUEST* SCARD_PCI_T1; /* equal to (&g_rgSCardT1Pci) */ + extern SCARD_IO_REQUEST* SCARD_PCI_RAW; /* equal to (&g_rgSCardRawPci) */ + + +#ifdef __cplusplus +extern "C" { +#endif + + +/* + * Smart Card service manager function + */ + +LONG WINAPI SCardEstablishContext( + DWORD dwScope, + LPCVOID pvReserved1, + LPCVOID pvReserved2, + LPSCARDCONTEXT phContext); + +LONG WINAPI SCardReleaseContext( + SCARDCONTEXT hContext); + +LONG WINAPI SCardFreeMemory( + SCARDCONTEXT hContext, + LPCVOID pvMem); + +HANDLE WINAPI SCardAccessStartedEvent(void); + +void WINAPI SCardReleaseStartedEvent( + HANDLE hStartedEventHandle); + +LONG WINAPI SCardIsValidContext( + SCARDCONTEXT hContext); + + +/* + * Smart Card database functions + */ + +LONG WINAPI SCardListReaderGroupsA( + SCARDCONTEXT hContext, + LPSTR mszGroups, + LPDWORD pcchGroups); +LONG WINAPI SCardListReaderGroupsW( + SCARDCONTEXT hContext, + LPWSTR mszGroups, + LPDWORD pcchGroups); + +#define SCardListReaderGroups WINELIB_NAME_AW(SCardListReaderGroups) + + +LONG WINAPI SCardListReadersA( + SCARDCONTEXT hContext, + LPCSTR mszGroups, + LPSTR mszReaders, + LPDWORD pcchReaders); +LONG WINAPI SCardListReadersW( + SCARDCONTEXT hContext, + LPCWSTR mszGroups, + LPWSTR mszReaders, + LPDWORD pcchReaders); + +#define SCardListReaders WINELIB_NAME_AW(SCardListReaders) + +LONG WINAPI SCardListCardsA( + SCARDCONTEXT hContext, + const BYTE* pbAtr, + LPCGUID rgquidInterfaces, + DWORD cguidInterfaceCount, + LPSTR mszCards, + LPDWORD pcchCards); +LONG WINAPI SCardListCardsW( + SCARDCONTEXT hContext, + const BYTE* pbAtr, + LPCGUID rgquidInterfaces, + DWORD cguidInterfaceCount, + LPWSTR mszCards, + LPDWORD pcchCards); + +#define SCardListCards WINELIB_NAME_AW(SCardListCards) + +LONG WINAPI SCardListInterfacesA( + SCARDCONTEXT hContext, + LPCSTR szCard, + LPGUID pguidInterfaces, + LPDWORD pcguidInterfaces); +LONG WINAPI SCardListInterfacesW( + SCARDCONTEXT hContext, + LPCWSTR szCard, + LPGUID pguidInterfaces, + LPDWORD pcguidInterfaces); + +#define SCardListInterfaces WINELIB_NAME_AW(SCardListInterfaces) + +LONG WINAPI SCardGetProviderIdA( + SCARDCONTEXT hContext, + LPCSTR szCard, + LPGUID pguidProviderId); +LONG WINAPI SCardGetProviderIdW( + SCARDCONTEXT hContext, + LPCWSTR szCard, + LPGUID pguidProviderId); + +#define SCardGetProviderId WINELIB_NAME_AW(SCardGetProviderId) + +LONG WINAPI SCardGetCardTypeProviderNameA( + SCARDCONTEXT hContext, + LPCSTR szCardName, + DWORD dwProviderId, + LPSTR szProvider, + LPDWORD pcchProvider); +LONG WINAPI SCardGetCardTypeProviderNameW( + SCARDCONTEXT hContext, + LPCWSTR szCardName, + DWORD dwProviderId, + LPWSTR szProvider, + LPDWORD pcchProvider); + +#define SCardGetCardTypeProviderName WINELIB_NAME_AW(SCardGetCardTypeProviderName) + +LONG WINAPI SCardIntroduceReaderGroupA( + SCARDCONTEXT hContext, + LPCSTR szGroupName); +LONG WINAPI SCardIntroduceReaderGroupW( + SCARDCONTEXT hContext, + LPCWSTR szGroupName); + +#define SCardIntroduceReaderGroup WINELIB_NAME_AW(SCardIntroduceReaderGroup) + +LONG WINAPI SCardForgetReaderGroupA( + SCARDCONTEXT hContext, + LPCSTR szGroupName); +LONG WINAPI SCardForgetReaderGroupW( + SCARDCONTEXT hContext, + LPCWSTR szGroupName); + +#define SCardForgetReaderGroup WINELIB_NAME_AW(SCardForgetReaderGroup) + + +LONG WINAPI SCardIntroduceReaderA( + SCARDCONTEXT hContext, + LPCSTR szReaderName, + LPCSTR szDeviceName); +LONG WINAPI SCardIntroduceReaderW( + SCARDCONTEXT hContext, + LPCWSTR szReaderName, + LPCWSTR szDeviceName); + +#define SCardIntroduceReader WINELIB_NAME_AW(SCardIntroduceReader) + +LONG WINAPI SCardForgetReaderA( + SCARDCONTEXT hContext, + LPCSTR szReaderName); +LONG WINAPI SCardForgetReaderW( + SCARDCONTEXT hContext, + LPCWSTR szReaderName); + +#define SCardForgetReader WINELIB_NAME_AW(SCardForgetReader) + +LONG WINAPI SCardAddReaderToGroupA( + SCARDCONTEXT hContext, + LPCSTR szReaderName, + LPCSTR szGroupName); +LONG WINAPI SCardAddReaderToGroupW( + SCARDCONTEXT hContext, + LPCWSTR szReaderName, + LPCWSTR szGroupName); + +#define SCardAddReaderToGroup WINELIB_NAME_AW(SCardAddReaderToGroup) + +LONG WINAPI SCardRemoveReaderFromGroupA( + SCARDCONTEXT hContext, + LPCSTR szReaderName, + LPCSTR szGroupName); +LONG WINAPI SCardRemoveReaderFromGroupW( + SCARDCONTEXT hContext, + LPCWSTR szReaderName, + LPCWSTR szGroupName); + +#define SCardRemoveReaderFromGroup WINELIB_NAME_AW(SCardRemoveReaderFromGroup) + +LONG WINAPI SCardIntroduceCardTypeA( + SCARDCONTEXT hContext, + LPCSTR szCardName, + LPCGUID pguidPrimaryProvider, + LPCGUID rgguidInterfaces, + DWORD dwInterfaceCount, + const BYTE* pbAtr, + const BYTE* pbAtrMask, + DWORD cbAtrLen); +LONG WINAPI SCardIntroduceCardTypeW( + SCARDCONTEXT hContext, + LPCWSTR szCardName, + LPCGUID pguidPrimaryProvider, + LPCGUID rgguidInterfaces, + DWORD dwInterfaceCount, + const BYTE* pbAtr, + const BYTE* pbAtrMask, + DWORD cbAtrLen); + +#define SCardIntroduceCardType WINELIB_NAME_AW(SCardIntroduceCardType) + +LONG WINAPI SCardSetCardTypeProviderNameA( + SCARDCONTEXT hContext, + LPCSTR szCardName, + DWORD dwProviderId, + LPCSTR szProvider); +LONG WINAPI SCardSetCardTypeProviderNameW( + SCARDCONTEXT hContext, + LPCWSTR szCardName, + DWORD dwProviderId, + LPCWSTR szProvider); + +#define SCardSetCardTypeProviderName WINELIB_NAME_AW(SCardSetCardTypeProviderName) + +LONG WINAPI SCardForgetCardTypeA( + SCARDCONTEXT hContext, + LPCSTR szCardName); +LONG WINAPI SCardForgetCardTypeW( + SCARDCONTEXT hContext, + LPCWSTR szCardName); + +#define SCardForgetCardType WINELIB_NAME_AW(SCardForgetCardType) + +LONG WINAPI SCardLocateCardsA( + SCARDCONTEXT hContext, + LPCSTR mszCards, + LPSCARD_READERSTATEA rgReaderStates, + DWORD cReaders); +LONG WINAPI SCardLocateCardsW( + SCARDCONTEXT hContext, + LPCWSTR mszCards, + LPSCARD_READERSTATEW rgReaderStates, + DWORD cReaders); + +#define SCardLocateCards WINELIB_NAME_AW(SCardLocateCards) + +LONG WINAPI SCardLocateCardsByATRA( + SCARDCONTEXT hContext, + LPSCARD_ATRMASK rgAtrMasks, + DWORD cAtrs, + LPSCARD_READERSTATEA rgReaderStates, + DWORD cReaders); +LONG WINAPI SCardLocateCardsByATRW( + SCARDCONTEXT hContext, + LPSCARD_ATRMASK rgAtrMasks, + DWORD cAtrs, + LPSCARD_READERSTATEW rgReaderStates, + DWORD cReaders); + +#define SCardLocateCardsByATR WINELIB_NAME_AW(SCardLocateCardsByATR) + +/* + * Smart card communication functions + */ + +LONG WINAPI SCardConnectA( + SCARDCONTEXT hContext, + LPCSTR szReader, + DWORD dwShareMode, + DWORD dwPreferredProtocols, + LPSCARDHANDLE phCard, + LPDWORD pdwActiveProtocol); +LONG WINAPI SCardConnectW( + SCARDCONTEXT hContext, + LPCWSTR szReader, + DWORD dwShareMode, + DWORD dwPreferredProtocols, + LPSCARDHANDLE phCard, + LPDWORD pdwActiveProtocol); + +#define SCardConnect WINELIB_NAME_AW(SCardConnect) + +LONG WINAPI SCardReconnect( + SCARDHANDLE hCard, + DWORD dwShareMode, + DWORD dwPreferredProtocols, + DWORD dwInitialization, + LPDWORD pdwActiveProtocol); + +LONG WINAPI SCardDisconnect( + SCARDHANDLE hCard, + DWORD dwDisposition); + +LONG WINAPI SCardBeginTransaction( + SCARDHANDLE hCard); + +LONG WINAPI SCardEndTransaction( + SCARDHANDLE hCard, + DWORD dwDisposition); + +LONG WINAPI SCardCancelTransaction( + SCARDHANDLE hCard); + +LONG WINAPI SCardControl( + SCARDHANDLE hCard, + DWORD dwControlCode, + LPCVOID pbSendBuffer, + DWORD cbSendLength, + LPVOID pbRecvBuffer, + DWORD cbRecvLength, + LPDWORD lpBytesReturned); + +LONG WINAPI SCardTransmit( + SCARDHANDLE hCard, + LPCSCARD_IO_REQUEST pioSendPci, + const BYTE* pbSendBuffer, + DWORD cbSendLength, + LPSCARD_IO_REQUEST pioRecvPci, + LPBYTE pbRecvBuffer, + LPDWORD pcbRecvLength); + +LONG WINAPI SCardCancel( + SCARDCONTEXT hContext); + + +/* + * Smart card tracking functions + */ + +LONG WINAPI SCardState( + SCARDHANDLE hCard, + LPDWORD pdwState, + LPDWORD pdwProtocol, + LPBYTE pbAtr, + LPDWORD pcbAtrLen); + +LONG WINAPI SCardStatusA( + SCARDHANDLE hCard, + LPSTR mszReaderNames, + LPDWORD pcchReaderLen, + LPDWORD pdwState, + LPDWORD pdwProtocol, + LPBYTE pbAtr, + LPDWORD pcbAtrLen); +LONG WINAPI SCardStatusW( + SCARDHANDLE hCard, + LPWSTR mszReaderNames, + LPDWORD pcchReaderLen, + LPDWORD pdwState, + LPDWORD pdwProtocol, + LPBYTE pbAtr, + LPDWORD pcbAtrLen); + +#define SCardStatus WINELIB_NAME_AW(SCardStatus) + +LONG WINAPI SCardGetStatusChangeA( + SCARDCONTEXT hContext, + DWORD dwTimeout, + LPSCARD_READERSTATEA rgReaderStates, + DWORD cReaders); +LONG WINAPI SCardGetStatusChangeW( + SCARDCONTEXT hContext, + DWORD dwTimeout, + LPSCARD_READERSTATEW rgReaderStates, + DWORD cReaders); + +#define SCardGetStatusChange WINELIB_NAME_AW(SCardGetStatusChange) + +LONG WINAPI SCardGetAttrib( + SCARDHANDLE hCard, + DWORD dwAttrId, + LPBYTE pbAttr, + LPDWORD pcbAttrLen); + +LONG WINAPI SCardSetAttrib( + SCARDHANDLE hCard, + DWORD dwAttrId, + const BYTE* pbAttr, + DWORD cbAttrLen); + + +#ifdef __cplusplus +} +#endif + +#endif + diff --git a/include/winsmcrd.h b/include/winsmcrd.h new file mode 100755 index 0000000..cc03a35 --- /dev/null +++ b/include/winsmcrd.h @@ -0,0 +1,190 @@ +/* + * 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 + */ + + +#ifndef _WINE_WINSCMCRD_H +#define _WINE_WINSCMCRD_H + + +#define MAX_ATR_SIZE 36 /* Maximum ATR size */ + +#ifndef SCARD_ATR_LENGTH +#define SCARD_ATR_LENGTH MAX_ATR_SIZE +#endif + +/* + * These values define the protocol used to + * communicate with the card + */ +#define SCARD_PROTOCOL_UNDEFINED 0x00000000 /* No protocol defined */ +#define SCARD_PROTOCOL_T0 0x00000001 /* T=0 protocol. */ +#define SCARD_PROTOCOL_T1 0x00000002 /* T=1 protocol */ +#define SCARD_PROTOCOL_RAW 0x00010000 /* Raw protocol, for memory card for example */ +#define SCARD_PROTOCOL_Tx (SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1) /* Can be used in SCardConnect */ + +/* + * The following value is used as a length value + * in functions where we want the winscard dll + * to allocate memory for us + */ +#define SCARD_AUTOALLOCATE (DWORD)(-1) + +/* + * Values used by SCardEstablishContext + */ +#define SCARD_SCOPE_USER 0x0000 /* context in user scope */ +#define SCARD_SCOPE_TERMINAL 0x0001 /* context in terminal scope */ +#define SCARD_SCOPE_SYSTEM 0x0002 /* context in system scope */ + +/* + * Flags used by SCardGetStatusChange to indicate + * the reader status. + */ +#define SCARD_STATE_UNAWARE 0x0000 /* called want to know the current state */ +#define SCARD_STATE_IGNORE 0x0001 /* don't update the state for the given reader */ +#define SCARD_STATE_CHANGED 0x0002 /* reader state has not changed */ +#define SCARD_STATE_UNKNOWN 0x0004 /* reader state unknown */ +#define SCARD_STATE_UNAVAILABLE 0x0008 /* reader state unavailable */ +#define SCARD_STATE_EMPTY 0x0010 /* no card on the reader*/ +#define SCARD_STATE_PRESENT 0x0020 /* card present on the reader */ +#define SCARD_STATE_ATRMATCH 0x0040 /* card's ATR matches the given ATR */ +#define SCARD_STATE_EXCLUSIVE 0x0080 /* an exclusive connection on the card exists*/ +#define SCARD_STATE_INUSE 0x0100 /* card in use but the connection can be shared */ +#define SCARD_STATE_MUTE 0x0200 /* card is mute, doesn't answer to reset */ +#define SCARD_STATE_UNPOWERED 0x0400 /* card present but not powered */ + + +/* + * These values define how SCardConnect should + * connect to the card + */ +#define SCARD_SHARE_EXCLUSIVE 0x0001 /* connect to the card in exclusive mode (no other connection allowed) */ +#define SCARD_SHARE_SHARED 0x0002 /* connection can be shared with others */ +#define SCARD_SHARE_DIRECT 0x0003 /* access directly the reader, no other connection allowed */ + +/* + * Values used by SCardDisconnect to specify + * how the card should be treated on closing + * the connection + */ +#define SCARD_LEAVE_CARD 0x0000 /* do nothing */ +#define SCARD_RESET_CARD 0x0001 /* reset the card */ +#define SCARD_UNPOWER_CARD 0x0002 /* unpower the card */ +#define SCARD_EJECT_CARD 0x0003 /* eject the card from the reader if supported */ + +/* + * Values returned by SCardStatus indicating + * the reader's state + */ +#define SCARD_UNKNOWN 0x0001 /* state unknown */ +#define SCARD_ABSENT 0x0002 /* no card on the reader */ +#define SCARD_PRESENT 0x0004 /* card is present on the reader */ +#define SCARD_SWALLOWED 0x0008 /* card inside the reader but not powered */ +#define SCARD_POWERED 0x0010 /* card present and powered */ +#define SCARD_NEGOTIABLE 0x0020 /* card present and ready to negotiate protocol */ +#define SCARD_SPECIFIC 0x0040 /* card has ended protocol negotiation */ + +/* + * definitions used by SCardGetAttrib and SCardSetAttrib for + * requesting and setting readers attributes + * Other values maybe supported + */ +#define SCARD_ATTR_ICC_PRESENCE 0x00090300 +#define SCARD_ATTR_CURRENT_PROTOCOL_TYPE 0x00080201 +#define SCARD_ATTR_ATR_STRING 0x00090303 +#define SCARD_ATTR_DEVICE_FRIENDLY_NAME_A 0x7FFF0003 +#define SCARD_ATTR_DEVICE_FRIENDLY_NAME_W 0x7FFF0005 +#define SCARD_ATTR_DEVICE_SYSTEM_NAME_A 0x7FFF0004 +#define SCARD_ATTR_DEVICE_SYSTEM_NAME_W 0x7FFF0006 + +#define SCARD_ATTR_DEVICE_FRIENDLY_NAME WINELIB_NAME_AW(SCARD_ATTR_DEVICE_FRIENDLY_NAME_) +#define SCARD_ATTR_DEVICE_SYSTEM_NAME WINELIB_NAME_AW(SCARD_ATTR_DEVICE_SYSTEM_NAME_) + +/* + * Type definitions used by all the functions + */ +typedef ULONG_PTR SCARDCONTEXT; +typedef SCARDCONTEXT *PSCARDCONTEXT; +typedef SCARDCONTEXT *LPSCARDCONTEXT; + +typedef ULONG_PTR SCARDHANDLE; +typedef SCARDHANDLE *PSCARDHANDLE; +typedef SCARDHANDLE *LPSCARDHANDLE; + + +/* + * SCARD_READERSTATE is used by SCardGetStatusChange as an + * input/output for any change of readers states + */ +typedef struct +{ + LPCSTR szReader; + void *pvUserData; + unsigned long dwCurrentState; + unsigned long dwEventState; + unsigned long cbAtr; + unsigned char rgbAtr[MAX_ATR_SIZE]; +} +SCARD_READERSTATEA; + +typedef struct +{ + LPCWSTR szReader; + void *pvUserData; + unsigned long dwCurrentState; + unsigned long dwEventState; + unsigned long cbAtr; + unsigned char rgbAtr[MAX_ATR_SIZE]; +} +SCARD_READERSTATEW; + +typedef SCARD_READERSTATEA *PSCARD_READERSTATEA, *LPSCARD_READERSTATEA; + +typedef SCARD_READERSTATEW *PSCARD_READERSTATEW, *LPSCARD_READERSTATEW; + +DECL_WINELIB_TYPE_AW(SCARD_READERSTATE) +DECL_WINELIB_TYPE_AW(PSCARD_READERSTATE) +DECL_WINELIB_TYPE_AW(LPSCARD_READERSTATE) + +/* + * This structure is used by SCardTransmit to communicate + * with the card + */ +typedef struct _SCARD_IO_REQUEST +{ + unsigned long dwProtocol; /* protocol used for this request */ + unsigned long cbPciLength; /* total length of the request data, usually sizeof(SCARD_IO_REQUEST) */ +} +SCARD_IO_REQUEST, *PSCARD_IO_REQUEST, *LPSCARD_IO_REQUEST; + +typedef const SCARD_IO_REQUEST *LPCSCARD_IO_REQUEST; + +/* + * This structure is used by the new functions + * SCardLocateCardsByATRA and SCardLocateCardsByATRW + */ +typedef struct _SCARD_ATRMASK { + unsigned long cbAtr; /* number of used bytes in rgbAtr and rgbMask*/ + unsigned char rgbAtr[MAX_ATR_SIZE]; /* ATR bytes of the card */ + unsigned char rgbMask[MAX_ATR_SIZE]; /* Mask used for accepted ATR values */ +} SCARD_ATRMASK; + +typedef SCARD_ATRMASK *PSCARD_ATRMASK, *LPSCARD_ATRMASK; + +#endif + -- 1.4.4.2

May 1, 2007

Re: Offer to upgrade the winehq Bugzilla

by Jeremy Newman

Seems like a fair deal to me. Bugzilla certainly needs the work. On Tue, 2007-05-01 at 14:14 +0200, Jan Zerebecki wrote: > The guy (nick mkanat) who admins buggbot on freenode (see > ##bugzilla-world ) said he would upgrade our bugzilla for us, > paid by his company "in exchange for a link in the footer or > front page, just mentioning that we did the upgrade". > > I'm not sure how much a link on the bugzilla page footer/menu is > worth in advertising revenue. There is already one on the wiki. > So maybe something like that link for a year in exchange for the > full upgrade work (producing and testing the diff for cvs and the > upgrade sql-script and fixing anything that breaks) sounds like a > fair deal. > > What should I respond? > > > Jan > > >

May 1, 2007

Re: [try2] gdi32 : Completes WidenPath Implementation

by Laurent Vromman

I have sent this patch last week with the correction Alexandre asked me to do. It is still not on the repository. Is there anything wrong again ? Any comments are welcomed and will be applied if necessary. Laurent Laurent Vromman a écrit : > This second try includes Alexandre comments and removes some obsolete > FIXME > Changelog : > Completes WidenPath implementation. > WidenPath recognizes PS_JOINs and PS_ENDCAPs > > --- > dlls/gdi32/path.c | 298 > +++++++++++++++++++++++++++++++++++++++++------------ > 1 files changed, 230 insertions(+), 68 deletions(-)

May 1, 2007

Re: How do I put a table of contents on one of our wiki pages?

by Dimi Paun

On Mon, 2007-04-30 at 23:40 -0700, Scott Ritchie wrote: > Does someone know? Yes, use: [[TableOfContents()]] Take a look at GitWine for an example: http://wiki.winehq.org/GitWine -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

May 1, 2007

Offer to upgrade the winehq Bugzilla

by Jan Zerebecki

The guy (nick mkanat) who admins buggbot on freenode (see ##bugzilla-world ) said he would upgrade our bugzilla for us, paid by his company "in exchange for a link in the footer or front page, just mentioning that we did the upgrade". I'm not sure how much a link on the bugzilla page footer/menu is worth in advertising revenue. There is already one on the wiki. So maybe something like that link for a year in exchange for the full upgrade work (producing and testing the diff for cvs and the upgrade sql-script and fixing anything that breaks) sounds like a fair deal. What should I respond? Jan

May 1, 2007

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

by Alexandre Julliard

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. > + 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. -- Alexandre Julliard julliard(a)winehq.org

May 1, 2007

Re: Direct3D viewport problems

by H. Verbeet

On 01/05/07, Robert Fairlie <rfairlie(a)kylebank.com> wrote: > Since iSize is only about a fifth of the window height, I would expect the > arrow to be displayed at the bottom left of the window. but it's actually > being displayed at the top left. The main part of the scene rendered with > the first viewport settings is fine. > > The code does as expected in Windows, so I was wondering if anyone knows of > any problems in this area. I'm also having problems with CD3DFont which I > think might be related to this. > Direct3D coordinates are flipped compared to GL coordinates, so it certainly sounds like a something that could go wrong. You didn't explicitly mention if you are rendering offscreen with the second viewport as well, but I'm assuming you are. Could you write a minimal test case to reproduce the problem? My initial guess would be that http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/state.c;h=1a0b… is the relevant code, but depending on the offscreen redering mode selected (in wine) there are potentially other places where things could go wrong as well.

May 1, 2007

Re: [PATCH 9/11] msi: automation: Expose Installer object.

by Alexandre Julliard

Misha Koshelev <mk144210(a)bcm.edu> writes: > --- > dlls/msi/automation.c | 6 ++++++ > dlls/msi/msi_main.c | 6 ------ > dlls/msi/msipriv.h | 3 +++ > dlls/msi/tests/automation.c | 38 +++++++++++++++++++++++++------------- The tests fail here: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so automation.c && touch automation.ok automation.c:353: Test failed: dispid wrong automation.c:475: Tests skipped: failed to create record automation.c:516: Test failed: IDispatch::GetIDsOfNames returned 0x80020006 automation.c:545: Test failed: IDispatch::Invoke returned 0x80020003 automation.c:558: Test failed: IDispatch::GetIDsOfNames returned 0x80020006 automation.c:1046: Test failed: Installer_OpenPackage failed, hresult 0x80020006 make: *** [automation.ok] Error 5 -- Alexandre Julliard julliard(a)winehq.org

May 1, 2007

Direct3D viewport problems

by Robert Fairlie

Hello, I'm having problems with DirectX viewports under Wine. I'm rendering to an offscreen surface and then copying the contents of the offscreen surface to a window. I first set the viewport to coincide with the window, i.e. vp.X = 0; vp.Y = 0; vp.Width = windowRect.Width(); vp.Height = windowRect.Height(); I render most of the the scene using the above viewport. I then need to draw an arrow in the bottom left hand corner of the of the window inside a square of side iSize, so I set: vp.X = 0; vp.Y = windowRect.Height() - iSize; vp.Width = iSize; vp.Height = iSize; Since iSize is only about a fifth of the window height, I would expect the arrow to be displayed at the bottom left of the window. but it's actually being displayed at the top left. The main part of the scene rendered with the first viewport settings is fine. The code does as expected in Windows, so I was wondering if anyone knows of any problems in this area. I'm also having problems with CD3DFont which I think might be related to this. Thanks for any advice, Robert Fairlie

May 1, 2007

How do I put a table of contents on one of our wiki pages?

by Scott Ritchie

The new FAQ is coming along fairly well, however it obviously needs a table of contents at this point. I combed through the documentation, but can't find anything. Does someone know? Thanks, Scott Ritchie

May 1, 2007