On Mon, Oct 31, 2011 at 23:27, Bruno Jesus <00cp...@gmail.com> wrote:
> try 3 - avoid magic constants by using winscard.h defines
> try 2 - split the patches and fix win2000 error
>
> This is the starting point for the winscard implementation. I'll add
> dozens of tes
On Wed, Oct 26, 2011 at 11:38, Marvin wrote:
> === W2KPROSP4 (32 bit winscard) ===
> winscard.c:53: Test failed: SCardIsValidContext expected
> SCARD_E_INVALID_HANDLE, received 0006
> winscard.c:64: Test failed: SCardReleaseContext expected
> SCARD_E_INVALID_HANDLE, received
anoid android.
=== W2KPROSP4 (32 bit winscard) ===
winscard.c:53: Test failed: SCardIsValidContext expected
SCARD_E_INVALID_HANDLE, received 0006
winscard.c:64: Test failed: SCardReleaseContext expected
SCARD_E_INVALID_HANDLE, received 0006
> >>
> >
> > OK, some notes:
> > "winscard: implementation" is a very bad name for a patch, especially for 4.
> > Splitting the patches is a good idea, but you need to split it different
> > (you are adding dead code).
> > In the first patch you might
On Thu, Oct 6, 2011 at 8:07 AM, Bruno Jesus <00cp...@gmail.com> wrote:
> ...
> This is a whole new feature, in my short period into wine developing
> this is the first time I see a completely new thing being introduced.
I'd take a look at usbd.sys, as it was introduced relatively recently.
Genera
2011/10/3 André Hentschel :
> Am 03.10.2011 09:31, schrieb Vincent Hardy:
>> First submitted on wine-devel and modified following comments from Marcus
>> Meissner (MAX_ATR_SIZE / bytecount).
>>
>
> OK, some notes:
> "winscard: implementation" is a ver
Am 03.10.2011 09:31, schrieb Vincent Hardy:
> First submitted on wine-devel and modified following comments from Marcus
> Meissner (MAX_ATR_SIZE / bytecount).
>
OK, some notes:
"winscard: implementation" is a very bad name for a patch, especially for 4.
Splitting the patches
of the same size and here we are
just transferring all bytes from pcsclite side to the WIN32 side.
That being said, maybe putting pStates[i].cbAtr will help the patches be
accepted.
By the way, I want to thank Vincent for taking the time to try to
incorporate the winscard code into Wine. Wit
On Fri, Sep 30, 2011 at 11:42:26AM +0200, Vincent Hardy wrote:
> Hi all,
>
> Here are four patches that are a partial but functional
> implementation of winscard.
>
> I installed "Belgian Electronic Identity Card MiddleWare"
> (http://eid-mw.googlecode.com/files/B
On 30/09/11 19:42, Vincent Hardy wrote:
>
> Are these 4 patches good enough to be sent to wine-patch ?
Vincent, normally you would start by adding tests that can confirm the
same behaviour in Windows. If you can do that and get the test accepted
then you are a long closer to get your patches accep
On Fri, Sep 30, 2011 at 06:42, Vincent Hardy wrote:
> Hi all,
>
> Here are four patches that are a partial but functional implementation of
> winscard.
Congratulations =)
> I installed "Belgian Electronic Identity Card MiddleWare"
> (http://eid-mw.googlecode.com/fi
Hi all,
Here are four patches that are a partial but functional implementation
of winscard.
I installed "Belgian Electronic Identity Card MiddleWare"
(http://eid-mw.googlecode.com/files/BeidMW35-6995.msi)
I tested winscard by starting beid35gui.exe and I can see my identity
Sergey Stepanov writes:
> @@ -33,6 +35,24 @@ const SCARD_IO_REQUEST g_rgSCardT0Pci = {
> SCARD_PROTOCOL_T0, 8 };
> const SCARD_IO_REQUEST g_rgSCardT1Pci = { SCARD_PROTOCOL_T1, 8 };
> const SCARD_IO_REQUEST g_rgSCardRawPci = { SCARD_PROTOCOL_RAW, 8 };
>
> +#define MAKE_FUNCPTR(f) static typeo
Hi Sergey,
#include "config.h"
+#include
#include
This change will cause compile failures on systems without this
header. You need to add a configure check for the header, and include
it conditionally.
Thanks,
--Juan
recommend tests to be stricter, e.g.
ok(result == SCARD_S_SUCCESS || result == SCARD_E_XYZ || broken(result ==
SCARD_E_...)
Here's work done last year by Yauheni Baltouski and Aliaksei Hud.
They are not working on winscard any more.
I'd be pleased to eventually see winscard tests in Wine
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=10750
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=10749
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=10722
Your paranoid android
Am 21.01.2011 09:53, schrieb vince:
> Hi all,
>
> I'm back with a smaller and reworked winscard patch.
>
> In respond to Vitaly Margolen
> (http://www.winehq.org/pipermail/wine-devel/2010-September/087017.html)
> 1. I used configure to get the so name of the librar
Hi all,
I'm back with a smaller and reworked winscard patch.
In respond to Vitaly Margolen
(http://www.winehq.org/pipermail/wine-devel/2010-September/087017.html)
1. I used configure to get the so name of the library.
2. I removed trailing spaces.
3. When this patch is approved, I will m
> To my knowledge the integration of the patches by Mounir IDRASSI has been
> rejected due to missing automated tests. This is a problem since for a full
> test someone has to write/provide an IFD handler which emulates some stuff.
IIRC, there was also a problem with the way it integration was don
nehq.org/pipermail/wine-devel/2007-May/057052.html
> >
> > What's the current state of PCSC support in Wine? When I recently looked,
> > winscard seemed full of stubs.
> >
> > OTOH, there's a company
> > http://www.starmoney.de/index.php?id=243
> >
joerg-cyril.hoe...@t-systems.com a écrit :
Hi,
looking for PCSC-card-reader support in Wine, I came across old mails from 2007.
http://www.winehq.org/pipermail/wine-devel/2007-May/057052.html
What's the current state of PCSC support in Wine? When I recently looked,
winscard seemed fu
Hi,
looking for PCSC-card-reader support in Wine, I came across old mails from 2007.
http://www.winehq.org/pipermail/wine-devel/2007-May/057052.html
What's the current state of PCSC support in Wine? When I recently looked,
winscard seemed full of stubs.
OTOH, there's a co
On Fri, Nov 7, 2008 at 10:27 AM, frechdachs69
<[EMAIL PROTECTED]> wrote:
> I am currently wondering which test cases make sense after an integration of
> winscard patches. So far most API calls are directly related to pcsc-lite
> behaviour and therefore we need a result from pcs
Hi together!
I am currently wondering which test cases make sense after an integration of
winscard patches. So far most API calls are directly related to pcsc-lite
behaviour and therefore we need a result from pcsc-lite which is comparable
with what Win/winscard.dll would return to us. But
ED]> wrote:
>
>> This patch corrects the declaration of the function
>> SCardReleaseStartedEvent of Winscard to match its definition in MSDN
>> found
>> in the following link :
>>
>> http://msdn.microsoft.com/en-us/library/aa379799(VS.85).aspx
>
>> -v
"Mounir IDRASSI" <[EMAIL PROTECTED]> wrote:
> This patch corrects the declaration of the function
> SCardReleaseStartedEvent of Winscard to match its definition in MSDN found
> in the following link :
>
> http://msdn.microsoft.com/en-us/library/aa379799(VS.
ith different names but this is useless as they are the same as
> the ones in winscard.
Unfortunately they aren't, the pcsclite headers use unsigned long
instead of DWORD for instance. This won't have the same size on
64-bit.
--
Alexandre Julliard
[EMAIL PROTECTED]
es in winscard. The only exception is for winscard handles: in
pcsclite they are always defined as "long", whereas in PSDK they are
defined as ULONG_PTR. So, for me, the only thing to do is convert those
handles back and forth from long to ULONG_PTR.
Another possible issue is when wine is
Mounir IDRASSI <[EMAIL PROTECTED]> writes:
> +/*
> + * pcsc-lite functions pointers
> + */
> +typedef LONG (*SCardEstablishContextPtr)(DWORD dwScope,LPCVOID pvReserved1,
> +LPCVOID pvReserved2, LPSCARDCONTEXT phContext);
> +typedef LONG (*SCardReleaseContextPtr)(SCARDCONTEXT hContext);
> +ty
The code is definitely cleaner with all your suggestions. I'm applying
them now.
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
> James wrote:
>> This would be a lot cleaner as:
>>
>> if (!(liteSCardEstablishContext = (SCardEstablishContextPtr)
>> wine_dlsym(g_pc
Thanks for your comments Juan.
Actually, the upcoming implementation checks the used function pointer at
each call and returns an error if not assigned. Also in it, winscard
always succeed to load even if pcsc-lite is not running. FYI, my first
winscard patch contains an advanced stage of the
CLite();
break;
}
I suspect it's safer not to fail loading winscard if PCSC-Lite isn't
available. Instead, the functions such as SCardListCards should probably
return empty lists. But knowing to do so relies on knowing that PCSC-Lite
couldn't be initialized,
James wrote:
This would be a lot cleaner as:
if (!(liteSCardEstablishContext = (SCardEstablishContextPtr)
wine_dlsym(g_pcscliteHandle,"SCardEstablishContext",szErr,sizeof(szErr)))
{
ERR("Failed to get SCardEstablishContext from pcsclite library. Error =
%s\n",szErr);
goto error;
}
I thi
On 5/23/07, Mounir IDRASSI <[EMAIL PROTECTED]> wrote:
Hi,
This patch adds helper variables and functions that exposes pcsc-lite
functionalities for the use of the upcoming implementation.
+/* loading entry points*/
+bSuccess = TRUE;
+if (bSuccess &&
+
Hi Alexandre,
You are completely right...these variables are definitely useless!! I
don't remember when I coded that but it must have been very late at night!
Anyway, I'll purge them from the patch.
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
Alexandre Julliar
Mounir IDRASSI <[EMAIL PROTECTED]> writes:
> +BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
> +{
> +TRACE("%p,%x,%p\n", hinstDLL, fdwReason, lpvReserved);
> +
> +switch (fdwReason)
> +{
> +case DLL_PROCESS_ATTACH:
> +{
> +
Hi Francois,
Thanks for your modifications. I'll review your patch and submit it if I
have no comments,
ِCheers,
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
Francois Gouget wrote:
> Hi,
>
> Here's a new version of the patch that removes the casts as suggested
>
: Francois Gouget <[EMAIL PROTECTED]>
Date: Wed May 16 02:45:51 2007 +0200
winscard: Add a stub dll (initial implementation by Mounir IDRASSI, bugs by Francois Gouget).
diff --git a/Makefile.in b/Makefile.in
index 30e0581..eb5307f 100644
--- a/Makefile.in
+++ b/Makefile.in
Hi,
Apart from Alexandre comment, I don't see any other possible changes.
So, if the first patch containing the API headers is OK, I can submit
the winscard stub patch.
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
Alexandre Julliard wrote:
> Francoi
Francois Gouget <[EMAIL PROTECTED]> writes:
> But then on a 64bit system an __int64 should be the same as a long so
> maybe it's ok anyway.
Yes, __int64 is a long on Win64.
> The only issue that could happen is if we try to compile Wine's dlls
> on a 64bit Windows system using Visual C++. Isn't
Alexandre Julliard wrote:
Francois Gouget <[EMAIL PROTECTED]> writes:
* I would really have liked to get rid of the (unsigneg int) casts, but
as the handle types are ULONG_PTRs it seems like it won't be possible.
That's quite annoying. If anyone has suggestions...
ULONG_PTRs are longs, they
Francois Gouget <[EMAIL PROTECTED]> writes:
> * I would really have liked to get rid of the (unsigneg int) casts, but
> as the handle types are ULONG_PTRs it seems like it won't be possible.
> That's quite annoying. If anyone has suggestions...
ULONG_PTRs are longs, they should be printed with
As I was working on the winscard headers, I also did small tweaks on the
winscard stub implementation. I admit it's mostly whitespace changes:
* removed unneeded #includes. They should be added back when the
implementation actually requires them.
* use LPCBYTE like in the headers inste
On Mo, 2007-04-30 at 00:58 +0200, Mounir IDRASSI wrote:
> +#define SCARD_S_SUCCESS0x
> +#define SCARD_F_INTERNAL_ERROR 0x8011 /**< An internal
> consistency check failed. */
> +#define SCARD_E_CANCELLED 0x8012 /**< The
> a
Hi all,
We have noticed that our first patch for winscard containing only the
headers have not been applied yet. Is this a normal delay? Is there any
pending issues? Should we send the remaining list of patches to complete
the winscard implementation?
Any comments/remarks are welcomed.
Cheers
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 (75
"Mounir IDRASSI" <[EMAIL PROTECTED]> wrote:
diff --git a/include/scarderr.h b/include/scarderr.h
new file mode 100755
index 000..c07833e
--- /dev/null
+++ b/include/scarderr.h
...
diff --git a/include/winscard.h b/include/winscard.h
new file mode 100755
index 000..f302a9f
--- /dev/null
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 [EMAIL PROTECTED]
A+
--
Eric Pouech
"The problem with designing something
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:
>
> sorr
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,
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
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 pa
oups ...sorry...It was my fault! You are as absolutely right.
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
Eric Pouech wrote:
> they should work across the whole buffer
> are you sure you don't pass -1 as the length for the input buffer ?
> A+
>
Mounir IDRASSI a écrit :
Hi Eric,
I have tested your hint concerning the final single call to
MultiByteToWideChar in order to convert the whole area but it didn't
work: even when I specify the whole length of the multi-string, it keeps
stoping at the first NULL character. I guess MultiByteToWideC
Hi Eric,
I have tested your hint concerning the final single call to
MultiByteToWideChar in order to convert the whole area but it didn't
work: even when I specify the whole length of the multi-string, it keeps
stoping at the first NULL character. I guess MultiByteToWideChar and
WideCharToMultiStri
d are
used without any problem.
However, there is still an issue: when when try to compile a source file
that uses them using winegcc, we get an unresolved symbol error. Did we
miss something? The only difference we see with msvcrt source is that
winscard exported variables have a structure as a
fference we see with msvcrt source is that
winscard exported variables have a structure as a type, whereas msvcrt
exported variables are pointers.
Cheers,
Mounir IDRASSI
IDRIX – Cryptography and IT Security Experts
http://www.idrix.fr
Eric Pouech wrote:
> from a cursory look, it looks a very go
Mounir IDRASSI a écrit :
Hi all,
We have managed to integrate our winscard source code into the wine source
tree, including the configure.ac and Makefine.in files.
As described in the developer's guide, I am attaching with this email the output of the
command "git format-patch or
On Monday 30 April 2007 00:58, Mounir IDRASSI wrote:
> Hi all,
> We have managed to integrate our winscard source code into the wine source
> tree, including the configure.ac and Makefine.in files. As described in the
> developer's guide, I am attaching with this email the outp
Am Mittwoch 25 April 2007 18:48 schrieb [EMAIL PROTECTED]:
> Hi,
> We have noticed that wine doesn't have the winscard dll responsible for the
> support of smart cards under windows. For the need of one of our projects,
> we are currently developing this dll for wine under L
Hi,
If there is a sample implementation or some kinda initial source code.
(Just send a initial code)
We can try to help you in integrating the code into wine tree.
By progressing step by step.
Thanks,
VJ
On 4/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Saulius Krasuckas <[EMAIL PROTE
Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
> IMHO it would be best for the community if you will start doing
> this immediatelly, not once done.
Unfortunately, we are well advanced and we can't do it that way due to other
constraints in the project.
Another bad point is that, since we are not re
I'm thrilled you're working on this!
I must urge you to submit code early and often to Wine.
The first patch you should send should just implement
a stub dll.
We can help you with that if you need it.
Here's a good example of a new stuff DLL:
http://winehq.org/pipermail/wine-patches/2007-April/03
ty if you will start doing
this immediatelly, not once done. Otherwise you would probably step in a
shoes of Transgaming' or Codeweavers' guys, patches from which src trees
will have a somwhat hard way into Wine tree.
> However, we would like to known the reason behind the lack of
Hi,
We have noticed that wine doesn't have the winscard dll responsible for the
support of smart cards under windows. For the need of one of our projects, we
are currently developing this dll for wine under Linux based on the pcsc-lite
library. Once done, we'll share it with the
67 matches
Mail list logo
