Wolfgang Glas wrote:
Am Montag, 14. August 2006 16:28 schrieb Douglas E. Engert:
Andreas Jellinghaus wrote:
Wolfgang Glas wrote:
1) Are there any good reasons to install the opensc dlls twice? (SCB
install directory and C:\WINDOWS\System32) Installing then only in the
SCB install directory should be IMHO sufficient, because all dlls on
which the opensc libs depeand are installed alongside in the same
directory, so they are resolved anyways.
no, any CSP will most likely require the DLL in system32 directory.
so yes, we should propably remove the copy in the scb directory.
but the other one is needed for any CSP to work - I guess.
I still think, that it would be the best solution to let the DLLs live in the
SCB diretory. IMHO a CSP is just another DLL. And any DLL resolves referenced
DLLs either in %PATH% or in the directory, where the DLL itself resides.
The newer Microsoft side-by-side installation of assemblies with manifests is
designed to get around all this. The VC++ 8.0 can output these, and its run time
routines are in an assembly in the WinSxS directory.
System32 is already crowded with more or less useful stuff with no chance to
find out, which file belongs to which packet. Please give the SCB-only
solution a try and check, whether we are facing any problem when not touching
the already-overcrowded System32 dir.
about the compiler foo:
if we want the DLL to work with a CSP I'm not sure mingw or cygwin will
get us anywhere.
MinGW produces very clen DLL files, which are dependant on msvcrt.dll No dll
dependencies on 'redistributables' like msvcr80.dll, every dependant DLL is
shipped with Win2K, WinXP and hpefully with Windows Vista.
These "redistributables" are the way Microsoft is addressing the DLL problems,
and i believe you will see a lot more of this in Vista.
The one thing I have not figured out is how these assembles get installed.
The Inno Setup Script software you are using to generate install packages
may not be up to date on installing side-by-side assemblies.
The latest version of MinGW's Win32 headers (w32api package) is in a very
advanced state, I was able to achieve even things like device and device
interface enumeration....
right now I hope to get my new build system based on visual studio 2005
c/express working soon and use that one.
Totally agree. Dlls in system32, and use the Micrsoft compiler,
so you will also be ready for Vista. Microsoft is still giving
away the compiler, so cost should not be an issue:
http://msdn.microsoft.com/vstudio/express/
:
That's what microsoft is telling everyone: "Use our new FOO 200x system and
you're ready for WIndows Vista". IMHO, VC8 introduces yet another
installation problem, the dependency on mscr80.dll. In one year you will find
your WinXP installation crowded with ate least10 different versions of this
DLL, installed from 10 different vendors.
I don't think so, not from different vendors, but maybe from Microsoft.
As best I can tell, the assembly is also digitally signed and may be updated
by "Windows Update".
The opensc.dll.manifest file generateed when opensc.dll is compiled with
VC++ 8.0 has:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT'
version='8.0.50608.0' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
and I think this ends up using the dlls in:
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd
There is also a:
C:\WINDOWS\WinSxS\Policies\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773
that talks about versions of the libraries, note the use of 8.0.50608.0 and
8.0.50727.42
in the two files.
Result: Waste of memory, all of
these packages will not profit of any security fix for this DLL. And, yes,
WinXP will be used for quite along time from now.
I disagree, I think Microsoft is setting up to allow security fixes, to
the VC++ run time.
At least for the next three
years WinXP will be the dominating Windows OS out there.
One issue is with instalation, as VC 2005 expects to find the
msvcr80.dll in something like:
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww
_0de06acd How does Microsoft say to package up the run time libs?
See above, the best solution would be a VC8 compiler/linker switch to use the
reduced API of msvcrt.dll, which should IMHO sufficient for opensc.
Would this work? Would mean using an older compiler?
A second
best solution put the burden to check for a mscr80.dll installed on your
system on the SCB installer program. This should be at least true for Windows
Vista. My experience showed, that I have to place msvc80.dll either in
system32 or SCB install dir in order to get a VC8-compiled opensc
operational.
No, not if you use the mt program to include the manifest with the
dll. See the patch I sent in last week that is now in SVN. It adds the
manifest to each dll and exe so the loader knows where to find the dlls.
OpenSSL also does this, and I was using OpenSSL-0.9.8b in my testing,
compiled with VC++ 8.0.
Having a Visual Studio Express Installation does not guarantee
to resolve mscr80.dll, you must either put the weird WinSxS-thing in you
%PATH% or install mscr80.dll alongside with your own software.
No. See the comments on the mt command to add the maifiest into to the DLL.
It can then find the dll.
The second
solution will be followed by most Software Vendors, leading to the problem I
described above.
I don't think so. I think they will embrace the Microsoft manifests,
and may even start creating their own assemblies. Maybe OpenSC could look
at this too, as there are a number of DLLs that have to go together,
including libeay32.dll, ssleay32.dll and libtdl3.dll. As long as they are not
assemblies then they could be included in a smart card bundle assembly.
The problem I see is with the Inno Setup Script, and how should the
Microsoft assemblies be installed. Might need a newer install script program.
This might have to be addressed first, and using VC+ 6.0 for the next SCB
might be better, if the install is not clean.
the last package was still compiled on a system with vs 2003.
If nothing else comes up I will work on all that on tuesday.
That would be very nice ;-) For now it seems, that VC8 is the best compromise,
hopefully Andreas will find a good way to tackle the mscr80.dll problem.
The use of the mt program after every link of a dll or exec solves the
mscr80.dll problem. Its install of the Microsoft assembly which has the
mscr80.dll that is the problem.
Wolfgang
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
