New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Universal Windows Platform (UWP) #143

Closed
smlu opened this Issue Mar 7, 2016 · 38 comments

Comments

Projects
None yet
7 participants
@smlu

smlu commented Mar 7, 2016

Are there any plans to update current codebase to be able to compile as a UWP library?
I have tried to compile Cryptopp source code as UWP static library but it failed. I can get it to compile with NO_OS_DEPENDENCE macro defined but then you lose for an example a OS based random number generator.

@smlu smlu changed the title from Universal Windows Platform (UWP) support to Support for Universal Windows Platform (UWP) Mar 7, 2016

@noloader

This comment has been minimized.

Collaborator

noloader commented Mar 8, 2016

I can get it to compile with NO_OS_DEPENDENCE macro defined but then you lose for an example a OS based random number generator.

Yeah, Crypto++ is mildly crippled under Windows Phone; but its incredibly crippled under Windows RT and UWP builds.

The random number generator was of concern to me when I did the ports a few years ago. So much so that I never published the procedures because I could not figure out how to do some things safely.

There are ways to generate random numbers but you have to work with one of Microsoft's managed APIs (Windows.Security.Cryptography). See How to generate secure random numbers under WinRT? and What cryptographically secure options are there for creating random numbers in WinRT?.


Are there any plans to update current codebase to be able to compile as a UWP library?

In an ideal world, we would integrate properly with the platform so that NO_OS_DEPENDENCE was not needed. I'd be game for it, but I've lost my taste for supporting Microsoft. If you develop some patches, I'd be happy to shepherd them through the process.

I've lost my taste because of Microsoft's marketing gimmicks, expiring trials on their tools, Metro UI on my Desktop (not a tablet), tying products and services, and constant stream of spam landing in my INBOX. I liked them better when they were a technology company with folks like Petzold, Richter and Robbins writing books about them. I guess this is what happens when marketing people run a tech company rather than tech people, and I really don't want to be around them anymore.

@noloader noloader added the Enhancement label Mar 8, 2016

@vukovinski

This comment has been minimized.

vukovinski commented Mar 12, 2016

I second the motion. I was foolishly confident in being able to port demoncrypt to UWP dotnet, but it happens that I'm a managed code junkie and can't even start to wrap my head around c++'s project hierarchy and dependencies'.
"A thin wrapper" - how hard could that be, I thought. :)

@lukapercic

This comment has been minimized.

lukapercic commented Mar 14, 2016

@noloader , sorry to hear about disappointment with microsoft policies. I know that it is tempting to just ignore them until they get their shit together for a couple of years. But that could be too late for developers that are planning to stick with crypto++.

UWP makes a lot of sense for crypto++. It can put our apps in the store, can better restrict access to our files/memory. Also, it is the same for PC, phone, and IOT windows. It should make the job of maintaining compatibility so much easier for crypto++.

Win32 is the dead end. It would work for a couple of years, and then just drop from the face of the earth, when the support ends.

@denisbider

This comment has been minimized.

Collaborator

denisbider commented Mar 15, 2016

I really don't expect the Win32 API to end any time soon. The Microsoft ecosystem is built on backward compatibility. If they ditch that, they can wave goodbye to their empire.

Unless Microsoft wants to shoot themselves in the head (not even foot), the Win32 API is likely to continue to exist for the foreseeable future.

@lukapercic

This comment has been minimized.

lukapercic commented Mar 15, 2016

"When the support ends", that often means in 12 years for microsoft.
They would at last rename it to Win64 if they want it to stick around :)

I was oversimplifying though- what i meant was;

  • Win32 will not be supported on arm devices (windows phone, continuum, iot core, even xbox),
  • win32 will not be in store,
  • it would be harder to assign your win32 app to open certain file types,
  • companies will start to enable policies where they will allow store apps, but restrict all win32 apps etc. (you know, cryptolockers & stuff)
  • also, UAC (User Account Control) will start poping up more and more for win32 calls.

To sum it up; apps with UWP (store apps) will be prefered by end-users because the whole eco-system will start pushing them (also, Store exposure). If the crypto++ will not support it, apps that realy on it will be at the disadvantage. Less adoption means less suport from the comunity in the long run.

@zabulus

This comment has been minimized.

Contributor

zabulus commented Mar 16, 2016

I've managed to setup crypto++ for UWP build using CMAKE and advice from http://stackoverflow.com/a/31924158/273577.
Main problem of compiling is wait functions used in socket implementations.
Tried to disable sockets at all, but undefing win32 sockets just turned on berkley sockets.
I will try to use NO_OS_DEPENDENCE define to disable sockets at all.

@zabulus

This comment has been minimized.

Contributor

zabulus commented Mar 16, 2016

With NO_OS_DEPENDENCE define build fails with following log:

1>------ Skipped Build: Project: RUN_TESTS, Configuration: Debug Win32 ------
1>Project not selected to build for this solution configuration 
2>------ Build started: Project: cryptest-object, Configuration: Debug Win32 ------
2>  test.cpp
2>  cryptest-object.vcxproj -> Y:\projects\cryptopp\UWP-32\cryptest-object.dir\Debug\cryptest-object.lib
3>------ Build started: Project: cryptopp-shared, Configuration: Debug Win32 ------
3>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification
3>rdrand.obj : error LNK2019: unresolved external symbol _MASM_RRA_GenerateBlock referenced in function "public: virtual void __thiscall CryptoPP::RDRAND::GenerateBlock(unsigned char *,unsigned int)" (?GenerateBlock@RDRAND@CryptoPP@@UAEXPAEI@Z)
3>rdrand.obj : error LNK2019: unresolved external symbol _MASM_RSA_GenerateBlock referenced in function "public: virtual void __thiscall CryptoPP::RDSEED::GenerateBlock(unsigned char *,unsigned int)" (?GenerateBlock@RDSEED@CryptoPP@@UAEXPAEI@Z)
3>Y:\projects\cryptopp\UWP-32\Debug\cryptopp-shared.dll : fatal error LNK1120: 2 unresolved externals
4>------ Build started: Project: cryptest, Configuration: Debug Win32 ------
4>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification
4>cryptopp-static.lib(rdrand.obj) : error LNK2019: unresolved external symbol _MASM_RRA_GenerateBlock referenced in function "public: virtual void __thiscall CryptoPP::RDRAND::GenerateBlock(unsigned char *,unsigned int)" (?GenerateBlock@RDRAND@CryptoPP@@UAEXPAEI@Z)
4>cryptopp-static.lib(rdrand.obj) : error LNK2019: unresolved external symbol _MASM_RSA_GenerateBlock referenced in function "public: virtual void __thiscall CryptoPP::RDSEED::GenerateBlock(unsigned char *,unsigned int)" (?GenerateBlock@RDSEED@CryptoPP@@UAEXPAEI@Z)
4>Y:\projects\cryptopp\UWP-32\Debug\cryptest.exe : fatal error LNK1120: 2 unresolved externals
5>------ Skipped Build: Project: INSTALL, Configuration: Debug Win32 ------
5>Project not selected to build for this solution configuration 
========== Build: 1 succeeded, 2 failed, 4 up-to-date, 2 skipped ==========
@zabulus

This comment has been minimized.

Contributor

zabulus commented Mar 16, 2016

I've manually added rdrand.asm to a generated cryptopp-object.vcxproj, set up custom build as specified in .\vs2010.zip\cryptlib.vcxproj. After that I've added rdrand-x86.obj output from previous file to cryptopp-shared.vcxproj and cryptopp-static.vcxproj.
After that all generated solution build is successfull.

It is all for x86 UWP. For x64 I think it will be the same. I'll try to compile for ARM.

@zabulus

This comment has been minimized.

Contributor

zabulus commented Mar 16, 2016

For ARM cmake-generated solution builds fine without error (and some features I suppose)

@smlu

This comment has been minimized.

smlu commented Mar 16, 2016

It is all for x86 UWP. For x64 I think it will be the same. I'll try to compile for ARM.

Did you build it without the NO_OS_DEPENDENCE macro defined?

@zabulus

This comment has been minimized.

Contributor

zabulus commented Mar 17, 2016

Did you build it without the NO_OS_DEPENDENCE macro defined?

Nope, I've defined NO_OS_DEPENDENCE. I've wrote above, that problems of build are in socket stuff mainly.
I think I can try to fix config.h to completely disable sockets, and see what causes build errors

@zabulus

This comment has been minimized.

Contributor

zabulus commented Mar 17, 2016

Here is log without NO_OS_DEPENDENCE

1>------ Skipped Build: Project: RUN_TESTS, Configuration: Debug Win32 ------
1>Project not selected to build for this solution configuration 
2>------ Build started: Project: cryptopp-object, Configuration: Debug Win32 ------
3>------ Build started: Project: cryptest-object, Configuration: Debug Win32 ------
3>  fipstest.cpp
2>  hrtimer.cpp
2>  osrng.cpp
2>  socketft.cpp
2>  wait.cpp
3>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\combaseapi.h(1173): error C3861: 'CoCreateInstanceFromApp': identifier not found
3>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\combaseapi.h(1194): error C3861: 'CoCreateInstanceFromApp': identifier not found
2>Y:\projects\cryptopp\hrtimer.cpp(107): error C3861: 'GetThreadTimes': identifier not found
3>Y:\projects\cryptopp\fipstest.cpp(288): error C3861: 'GetModuleHandleW': identifier not found
3>Y:\projects\cryptopp\fipstest.cpp(302): error C3861: 'GetModuleHandleA': identifier not found
2>Y:\projects\cryptopp\wait.cpp(145): error C3861: 'PulseEvent': identifier not found
2>Y:\projects\cryptopp\wait.cpp(303): error C3861: 'PulseEvent': identifier not found
2>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\combaseapi.h(1173): error C3861: 'CoCreateInstanceFromApp': identifier not found (compiling source file Y:\projects\cryptopp\osrng.cpp)
2>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\combaseapi.h(1194): error C3861: 'CoCreateInstanceFromApp': identifier not found (compiling source file Y:\projects\cryptopp\osrng.cpp)
2>Y:\projects\cryptopp\osrng.cpp(50): error C3861: 'CryptAcquireContext': identifier not found
2>Y:\projects\cryptopp\osrng.cpp(83): error C3861: 'CryptGenRandom': identifier not found
2>Y:\projects\cryptopp\socketft.cpp(99): error C3861: 'CancelIo': identifier not found
2>Y:\projects\cryptopp\socketft.cpp(352): error C3861: 'CancelIo': identifier not found
2>Y:\projects\cryptopp\socketft.cpp(434): error C3861: 'CancelIo': identifier not found
4>------ Build started: Project: cryptopp-static, Configuration: Debug Win32 ------
5>------ Build started: Project: cryptopp-shared, Configuration: Debug Win32 ------
5>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification
4>LINK : fatal error LNK1181: cannot open input file 'Y:\projects\cryptopp\UWP-32_OS\cryptopp-object.dir\Debug\hrtimer.obj'
6>------ Build started: Project: cryptest, Configuration: Debug Win32 ------
5>LINK : fatal error LNK1181: cannot open input file 'Y:\projects\cryptopp\UWP-32_OS\cryptopp-object.dir\Debug\hrtimer.obj'
6>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification
6>LINK : fatal error LNK1181: cannot open input file 'Debug\cryptopp-static.lib'
7>------ Skipped Build: Project: INSTALL, Configuration: Debug Win32 ------
7>Project not selected to build for this solution configuration 
========== Build: 0 succeeded, 5 failed, 2 up-to-date, 2 skipped ==========
2>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\combaseapi.h(1173): error C3861: 'CoCreateInstanceFromApp': identifier not found (compiling source file Y:\projects\cryptopp\osrng.cpp)
2>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\combaseapi.h(1194): error C3861: 'CoCreateInstanceFromApp': identifier not found (compiling source file Y:\projects\cryptopp\osrng.cpp)

These problems caused by #define _WIN32_WINNT 0x0400 in fipstest.cpp
I think that for UWP these must be undefined

3>Y:\projects\cryptopp\fipstest.cpp(288): error C3861: 'GetModuleHandleW': identifier not found
3>Y:\projects\cryptopp\fipstest.cpp(302): error C3861: 'GetModuleHandleA': identifier not found

These function are undefined for WINAPI_PARTITION_APP partition. These functions are used for reading module from memory.

2>Y:\projects\cryptopp\wait.cpp(145): error C3861: 'PulseEvent': identifier not found
2>Y:\projects\cryptopp\wait.cpp(303): error C3861: 'PulseEvent': identifier not found
2>Y:\projects\cryptopp\socketft.cpp(99): error C3861: 'CancelIo': identifier not found
2>Y:\projects\cryptopp\socketft.cpp(352): error C3861: 'CancelIo': identifier not found
2>Y:\projects\cryptopp\socketft.cpp(434): error C3861: 'CancelIo': identifier not found

Socket stuff

@zabulus

This comment has been minimized.

Contributor

zabulus commented Mar 17, 2016

Did you build it without the NO_OS_DEPENDENCE macro defined?

What OS-specific features do you need for UWP build? AFAIU, NO_OS_DEPENDENCE turns off socket stuff and Microsoft's CryptoAPI.
For UWP CryptoAPI surface is undefined and socket stuff won't work because of other undefined PulseEvent and CancelIo.
So I don't see any purpose in UWP without NO_OS_DEPENDENCE.

@smlu

This comment has been minimized.

smlu commented Mar 17, 2016

What OS-specific features do you need for UWP build?

Mainly I would need OS based random number generator. NO_OS_DEPENDENCE macro turns this off as you know.

For UWP CryptoAPI surface is undefined

CryptoAPI was replaced by Cryptography API: Next Generation (CNG) (by the way Windows Vista already supports this).
CNG has two API suits: Bcrypt and NCrypt. NCrypt is an application layer between your app and os for key storing operations. Basically it should be used to protect in memory sensitive data(keys) of your app, but correct me there if I am wrong. BCrypt is for all other cryptographic/security operations.
For an example: to use OS random number generator in UWP app, cryptopp should be ported to use BCryptGenRandom function instead of current WIN32 CryptGenRandom func.

... and socket stuff won't work because of other undefined PulseEvent and CancelIo

As for the matter of sockets UWP app should be able to work with Windows Sockets 2 API at least the documentation says so.
There is also Windows RT C++ support (merge of Modern C++) that can be used. It has new API for dealing with networking like StreamSockets, DatagramSockets, WebSockets.

...undefined PulseEvent and CancelIo

All calls to PulseEvent should be replaced by condition variables because call to it is unreliable. The documentation mentions this here (see Remarks section).
Calls to CancelIo can be replaced by calls to CancelIoEx.
From your build log I can also see that there is a problem with GetThreadTimes, GetModuleHandleW and GetModuleHandleA functions. I think this can be also solved somehow.

Unfortunately, currently I do not have much time to port Crypto++ to UWP but if there is anybody willing to do this I will be glad to help as much as i will be able to.

.

@zabulus

This comment has been minimized.

Contributor

zabulus commented Mar 17, 2016

CryptoAPI was replaced by Cryptography API: Next Generation (CNG) (by the way Windows Vista already supports this).
CNG has two API suits: Bcrypt and NCrypt. NCrypt is an application layer between your app and os for key storing operations. Basically it should be used to protect in memory sensitive data(keys) of your app, but correct me there if I am wrong. BCrypt is for all other cryptographic/security operations.
For an example: to use OS random number generator in UWP app, cryptopp should be ported to use BCryptGenRandom function instead of current WIN32 CryptGenRandom func.

Yep this API is exposed for UWP, but not implemented in crypto++. And I think this is separate task for crypto++.

Calls to CancelIo can be replaced by calls to CancelIoEx.

Hm, interesting. Indeed CancelIoEx can be used in UWP API surface. Good.

@noloader

This comment has been minimized.

Collaborator

noloader commented Apr 24, 2016

@zabulus, - @smlu - I'm sincere about helping you shepherd things through the process. How is the patch coming along? Does anyone have anything to share?

Also, I need a test script for Windows that builds the various Visual Studio configurations under a Developer Command Prompt using msbuild. That will allow me to _easily_ test changes like these under Win32, Win64, Windows Phone, ARM etc. Does anyone have Windows scripting abilities?

I'll take any basic script I can get my hands on. Once the basic script is done, I can continue to add test cases as we identify sore spots. Here's what the test script looks like on Linux, OS X and Unix: cryptest.sh. The *nix script started small and it quickly grew.

@noloader

This comment has been minimized.

Collaborator

noloader commented Apr 24, 2016

@zabulus, @smlu -

For an example: to use OS random number generator in UWP app, cryptopp should be ported to use BCryptGenRandom function instead of current WIN32 CryptGenRandom func.

Yep this API is exposed for UWP, but not implemented in crypto++. And I think this is separate task for crypto++.

This would be a very good first patch. First, identify the preprocessor defines that allow us to determine UWP platform. Then, add the relevant code guarded by the preprocessor macro. Add it as a blocking generator in osrng.h.

@zabulus

This comment has been minimized.

Contributor

zabulus commented Apr 24, 2016

@noloader
Here is my branch with UWP:
master...zabulus:UWP_Build
What I had already done:

  • Added preprocessor definition CRYPTOPP_WIN_UWP_AVAILABLE
  • Adopted PR #156 for compilation of asm files using CMake.
  • All places where CRYPTOPP_WIN32_AVAILABLE check were used I've added CRYPTOPP_WIN_UWP_AVAILABLE except places where it not needed.
  • Implemented in osrng.cpp NonblockingRng using BCryptGenRandom API.
  • Replaced CancelIO with CacnelIOEx for UWP
  • Made same replace for GetOverlappedResult with GetOverlappedResultEx

I ran cryptest.sh on my hyper-v xubunty, but VM hanged during night work in the middle of run. So I can't be sure everything works on *nix. Though, I've found and fixed build issue for *nix. I'll re-run it.

As for analogue for cryptest.sh but for MSBuild. What VC compilers should it check?

@zabulus

This comment has been minimized.

Contributor

zabulus commented Apr 24, 2016

And forgot to mention. PulseEvent function is not supported in UWP, and it is unreliable for use. I've replaced it with SetEvent, but I'm not sure it is right change.

@zabulus

This comment has been minimized.

Contributor

zabulus commented Apr 24, 2016

As for analogue for cryptest.sh but for MSBuild. What VC compilers should it check?

I think this and other questions should be discussed in separate issue.

@noloader

This comment has been minimized.

Collaborator

noloader commented Apr 24, 2016

@zabulus - the BlockingRNG code looks about right to me. Would it be possible to separate it from the other changes and work this as a unique task? The RNG issues are blocking in my mind's eye, and we can get to the other changes later.

@noloader

This comment has been minimized.

Collaborator

noloader commented Apr 24, 2016

As for analogue for cryptest.sh but for MSBuild. What VC compilers should it check?

I think this and other questions should be discussed in separate issue.

Now open.... Issue 159: Need cryptest.cmd for Windows testing

@zabulus

This comment has been minimized.

Contributor

zabulus commented Apr 24, 2016

@zabulus - the BlockingRNG code looks about right to me. Would it be possible to separate it from the other changes and work this as a unique task? The RNG issues are blocking in my mind's eye, and we can get to the other changes later.

Sure I can, but it depends on CRYPTOPP_WIN_UWP_AVAILABLE definition. Or should I replace CRYPTOPP_WIN32_AVAILABLE implementation with it?

@noloader

This comment has been minimized.

Collaborator

noloader commented Apr 24, 2016

but it depends on CRYPTOPP_WIN_UWP_AVAILABLE definition. Or should I replace CRYPTOPP_WIN32_AVAILABLE implementation with it?

Yes, of course. I know you are going to need to tweak config.h.

It looks like CRYPTOPP_WIN_UWP_AVAILABLE is used to detect Metro UI and App Store apps rather than UWP. So my question would be one of two: (1) is CRYPTOPP_WIN_UWP_AVAILABLE the appropriate name; or (2) what can you do to detect UWP?

Detecting Windows App Store platform is OK. I think that would make it useful for Windows 8, too. But if that's what you are doing, then name it appropriately :)


On a related note, what is the Windows 8 and above "App Store app" platform called now a days? Its been through so many name changes and marketing gimmicks, I can't really tell how to unequivocally identify it so everyone knows what we are talking about.

@zabulus

This comment has been minimized.

Contributor

zabulus commented Apr 24, 2016

It looks like CRYPTOPP_WIN_UWP_AVAILABLE is used to detect Metro UI and App Store apps rather than UWP. So my question would be one of two: (1) is CRYPTOPP_WIN_UWP_AVAILABLE the appropriate name; or (2) what can you do to detect UWP?

Let's start from the beginning.

  1. I'm using CMake to generate .vcxproj and .sln files. For UWP I've used additional options, as specified here: http://stackoverflow.com/a/31924158/273577.
  2. CMake generates Universal Windows projects for cryptopp-object and others. In preprocessor defines of project there is define WINAPI_FAMILY=WINAPI_FAMILY_APP.
  3. I'm using this WINAPI_FAMILY define. If it's value not set to WINAPI_PARTITION_DESKTOP, which means traditional desktop applications, then it is UWP library. WINAPI_PARTITION_DESKTOP is the widest API partition, and WINAPI_FAMILY_APP is the smallest API partition and the smallest common denominator of new windows API surface.
  4. I assume that there will be two possible values of WINAPI_FAMILY: WINAPI_PARTITION_DESKTOP and not WINAPI_PARTITION_DESKTOP. For first, it will be used old CRYPTOPP_WIN32_AVAILABLE for everything else CRYPTOPP_WIN_UWP_AVAILABLE
@noloader

This comment has been minimized.

Collaborator

noloader commented Apr 24, 2016

@zabulus,

According to Guide to Universal Windows Platform (UWP) apps on Technet, its Windows 10 and above. However, I know that WINAPI_FAMILY is Windows 8 and Windows Phone and its tied to the Metro UI. I guess that's my point of disconnect on the naming.

So let's do this... call it CRYPTOPP_WINAPP_AVAILABLE or CRYPTOPP_WINRT_AVAILABLE. That should capture the new Windows Runtime APIs.

Also see Don’t call them Metro: Microsoft rebrands Universal apps as “Windows apps”.

@zabulus

This comment has been minimized.

Contributor

zabulus commented Apr 24, 2016

According to winapifamily.h

  • WINAPI_PARTITION_APP // usable for Windows Universal store apps

Rebranding went no so well :)
OK, I think CRYPTOPP_WINRT_AVAILABLE looks best. I'll rename it

@noloader

This comment has been minimized.

Collaborator

noloader commented Apr 24, 2016

Here's something I had to do when i performed the initial ports a few years ago: I had to force include <winapifamily.h> when needed. From there, I could set a macro like CRYPTOPP_WINRT_AVAILABLE. Keep it in your back pocket in case you need it.

Force include is documented at /FI (Name Forced Include File) on MSDN.

Also keep in mind we want to avoid including header files in Crypto++'s <config.h>. That particular file should be clean of includes. Its why we don't include Apple's <TargetConditionals.h>.

@noloader

This comment has been minimized.

Collaborator

noloader commented Apr 25, 2016

Here's what I tossed together for testing compiles and links from the command line. It should mostly work out of the box. For ARM, I had to remove rdrand.cpp and rdrand.obj by hand. in the future, I think we should re-jigger it so rdrand does not need special handling.

Testing under ARM is showing some linker problems. The same linker problems should show up under under x86 and x64 when compiling Windows App Store/Metro UI apps.

LIB_SRCS = cryptlib.cpp cpu.cpp shacal2.cpp md5.cpp shark.cpp zinflate.cpp gf2n.cpp salsa.cpp xtr.cpp oaep.cpp rc2.cpp default.cpp wait.cpp wake.cpp twofish.cpp iterhash.cpp adler32.cpp elgamal.cpp marss.cpp blowfish.cpp ecp.cpp filters.cpp strciphr.cpp camellia.cpp ida.cpp zlib.cpp des.cpp crc.cpp algparam.cpp dessp.cpp tea.cpp eax.cpp network.cpp emsa2.cpp pkcspad.cpp squaretb.cpp idea.cpp authenc.cpp hmac.cpp zdeflate.cpp xtrcrypt.cpp mars.cpp rc5.cpp queue.cpp hrtimer.cpp vmac.cpp eprecomp.cpp hex.cpp tiger.cpp dsa.cpp sha.cpp fips140.cpp gzip.cpp seal.cpp blake2.cpp files.cpp base32.cpp tigertab.cpp sharkbox.cpp safer.cpp randpool.cpp esign.cpp arc4.cpp osrng.cpp skipjack.cpp seed.cpp integer.cpp sha3.cpp sosemanuk.cpp bfinit.cpp rabin.cpp 3way.cpp rw.cpp  rsa.cpp rdtables.cpp gost.cpp socketft.cpp tftables.cpp nbtheory.cpp panama.cpp modes.cpp rijndael.cpp casts.cpp chacha.cpp gfpcrypt.cpp poly1305.cpp dll.cpp ec2n.cpp polynomi.cpp blumshub.cpp algebra.cpp basecode.cpp base64.cpp cbcmac.cpp rc6.cpp dh2.cpp gf256.cpp mqueue.cpp misc.cpp pssr.cpp channels.cpp cast.cpp rng.cpp square.cpp asn.cpp whrlpool.cpp md4.cpp dh.cpp ccm.cpp md2.cpp mqv.cpp gf2_32.cpp ttmac.cpp luc.cpp trdlocal.cpp pubkey.cpp gcm.cpp ripemd.cpp ocb.cpp eccrypto.cpp serpent.cpp cmac.cpp

LIB_OBJS = cryptlib.obj cpu.obj shacal2.obj md5.obj shark.obj zinflate.obj gf2n.obj salsa.obj xtr.obj oaep.obj rc2.obj default.obj wait.obj wake.obj twofish.obj iterhash.obj adler32.obj elgamal.obj marss.obj blowfish.obj ecp.obj filters.obj strciphr.obj camellia.obj ida.obj zlib.obj des.obj crc.obj algparam.obj dessp.obj tea.obj eax.obj network.obj emsa2.obj pkcspad.obj squaretb.obj idea.obj authenc.obj hmac.obj zdeflate.obj xtrcrypt.obj mars.obj rc5.obj queue.obj hrtimer.obj vmac.obj eprecomp.obj hex.obj tiger.obj dsa.obj sha.obj fips140.obj gzip.obj seal.obj blake2.obj files.obj base32.obj tigertab.obj sharkbox.obj safer.obj randpool.obj esign.obj arc4.obj osrng.obj skipjack.obj seed.obj integer.obj sha3.obj sosemanuk.obj bfinit.obj rabin.obj 3way.obj rw.obj rsa.obj rdtables.obj gost.obj socketft.obj tftables.obj nbtheory.obj panama.obj modes.obj rijndael.obj casts.obj chacha.obj gfpcrypt.obj dll.obj ec2n.obj polynomi.obj blumshub.obj algebra.obj basecode.obj base64.obj cbcmac.obj rc6.obj dh2.obj gf256.obj mqueue.obj misc.obj pssr.obj channels.obj cast.obj rng.obj square.obj asn.obj whrlpool.obj md4.obj dh.obj ccm.obj md2.obj mqv.obj gf2_32.obj ttmac.obj luc.obj trdlocal.obj pubkey.obj gcm.obj ripemd.obj eccrypto.obj serpent.obj cmac.obj

TEST_SRCS = bench1.cpp bench2.cpp test.cpp validat1.cpp validat2.cpp validat3.cpp adhoc.cpp datatest.cpp regtest.cpp fipsalgt.cpp dlltest.cpp

TEST_OBJS = bench1.obj bench2.obj test.obj validat1.obj validat2.obj validat3.obj datatest.obj regtest.obj fipsalgt.obj dlltest.obj

CXX = cl.exe 
LD = link.exe
AR = lib.exe
RM = del.exe

CPPFLAGS = /nologo /D_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 /EHsc
CXXFLAGS = /nologo /D_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 /EHsc
LDFLAGS = /nologo
ARFLAGS = /nologo

all: cryptest.exe

cryptest.exe: cryptlib.lib $(TEST_OBJS)
    $(LD) $(LDFLAGS) cryptlib.lib $(TEST_OBJS) /out:$@

cryptlib.lib : $(LIB_OBJS)
    $(AR) $(ARFLAGS) $(LIB_OBJS) /out:$@

clean:
    $(RM) /F /Q $(LIB_OBJS) $(TEST_OBJS) cryptlib.lib cryptest.exe

Save the file as, say cryptest.nmake. Then:

  • Open a Developer Prompt
  • Execute cls && nmake /f cryptest.nmake
@noloader

This comment has been minimized.

Collaborator

noloader commented Apr 25, 2016

@smlu, @vukovinski, @zabulus,

I checked in cryptest.nmake today. It will allow us to perform basic testing for Windows Phone and Windows Store apps using nmake from the command line. Its already started revealing minor problems, like Issue 162: Compile issues for crc.cpp and blake2.cpp under ARM Developer Prompt.

cryptest.nmake is is a moving target at the moment. Its still needs some minor tuning. It was checked in early so folks could get their hands on it and supply feedback.

Eventually, I'd like to get a script together that repeatedly calls it with different CPPFLAGS and different CXXFLAGS. I should be able to provide it since I have basic Windows scripting skills. We will still need something that tests the Visual Studio solution and its 24 configurations with MSBuild.

@zabulus

This comment has been minimized.

Contributor

zabulus commented Apr 27, 2016

OK, I think CRYPTOPP_WINRT_AVAILABLE looks best. I'll rename it

Renamed.

@noloader

This comment has been minimized.

Collaborator

noloader commented Apr 27, 2016

@smlu, @vukovinski, @zabulus,

Could comeone provide a patch for the Random Number generator only at Issue 164: Need NonblockingRng based on BCryptGenRandom for Windows?

@zabulus

This comment has been minimized.

Contributor

zabulus commented Apr 28, 2016

Could comeone provide a patch for the Random Number generator only at Issue 164: Need NonblockingRng based on BCryptGenRandom for Windows?

I could. But I not quite understand relation with CRYPTOPP_WINRT_AVAILABLE define. Do you want patch with #ifdef CRYPTOPP_WINRT_AVAILABLE guard but without CRYPTOPP_WINRT_AVAILABLE define itself in config? Am I understood correct?

@noloader

This comment has been minimized.

Collaborator

noloader commented May 2, 2016

@smlu, @vukovinski, @zabulus, @denisbider

I think the Windows Phone and Windows Store port is ready to be tested. There's a new branch called windows-store. If there are no complaints, then we can merge it next week some time.

I've tested under Visual Studio 2010, 2012 and 2013 from the IDE, which verified the compile and self tests for x86 and x64. I also tested from the command line with ARM, which verified the compile for Windows Phone and Windows Store.

I don't know what's going to happen on MinGW. I asked for testers but got no responses.

@noloader

This comment has been minimized.

Collaborator

noloader commented May 2, 2016

Now open on the Crypto++ mailing list: Windows Phone, Windows Store and testing.

@noloader

This comment has been minimized.

Collaborator

noloader commented May 17, 2016

The windows-store branch was merged into master. This issue is now resolved.

Git does not provide a log entry for the merger (or I cannot find it), so I don't have a record to offer for the transaction.

@DiskGetor

This comment has been minimized.

DiskGetor commented May 2, 2018

getoverlappedresultex error wiith windows7 X64 debug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment