I am writing a program for Windows 8 that encrypts a lot of data (over 100MB at a time) and have noticed that even when using multi-threading, the encryption APIs on Windows 8 are slower than the Cryptographic Service Providers (CSPs) on previous versions of Windows. I was wondering if there was a faster way to encrypt files using AES on Windows 8.
Microsoft CryptoAPI Next Generation (CNG) is a successor of old CSPs,it's fully native. First implemented in Windows Vista, it is still available in W8.
Why not to use them?
You can try the SecureBlackbox library, it is commercial (with free trial), but implements all the stuff on it's own.
And, anyway, any managed code will be somehow slower than native one.
Related
I have an embedded device with WinCE 6.0 as OS. The manufacturer provides an IDE for 3rd party development to it. The IDE pretty much allows nothing else than
.NET 3.5 Compact Framework scripting that's invoked from various events from the main application
Adding files to the device.
The included mediaplayer seems to be using DirectShow and the OS has media codec only for mpeg-1 encoded video playback. My goal is to to be able to play media encoded with some other codecs as well inside that main application.
I've already managed to use DirectShowNETCF (DirectShow wrapper for .NET Compact Framework) and successfully playback mpeg-1 encoded video.
I'm totally new with this stuff and I have tons of (stupid) questions. I'll try to narrow them down:
The OS is based on WinCE, but as far as I've understood, it's actually always some customized version of it (via Platform Builder). Only "correct way" of developing anything for it afterwards is to use the SDK the manufacturer usually provides. Right? In my case, the SDK is extremely limited and tightly integrated into IDE as noted above. However, .NET CF 3.5 is capable for interop so its possible to call native libraries -as long as they are compiled for correct platform.
Compiled code is pretty much just instructions for the processor (assembler code) and the compiler chooses the correct instructions based on the target processor setting. Also there's the PE-header that defines under which platform the program is meant to be run. If I target my "helloworld.exe" (does nothing but returns specific exit code) to x86 and compile it with VC, should it work?
If the PE-header is in fact the problem, is it possible to setup for WINCE without the SDK? Do I REALLY need the whole SDK for creating a simple executable that uses only base types? I'm using VS2010, which doesn't even support smart device dev anymore and I'd hate to downgrade just for testing purposes.
Above questions are prequel to my actual idea: Porting ffmpeg/ffdshow for WinCE. This actually already exists, but not targeted nor built for Intel Atom. Comments?
If the native implementation is not possible and I would end up implementing some specific codec with C#...well that would probably be quite a massive task. But having to choose C# over native, could I run into problems with codec performance? I mean.. is C# THAT much slower?
Thank you.
I've not seen an OEM that shipped their own IDE, but it's certainly possible. That shouldn't change how apps can created, however. It's possible that they've done a lot of work to make sure only things from their IDE work, but that would be a serious amount of work for not that much benefit, so I'd think it's unlikely.
As for your specific questions:
The OS is Windows CE, not "based on" it. The OS is, however, componentized, so not all pieces are going to be available. An SDK generally provides a mechanism to filter out what isn't available. You can actually use any SDK that targets the right processor architecture, but if your app calls into a library for something that isn't in the OS, then you'll get at the very least an error. For managed code this is all not relevant because the CF isn't componentized. If it's there, and CF app can run (and if it's not, you can often install it after the fact). This means that if the platform supports the CF, then you can write a CF app and run it. That app can then call native stuff via P/Invoke (unless, of course, the OS creator decided to add security to prevent that. This is possible in the OS, though I've never seen it implemented).
Yes, compiled code is just "instructions". For native, yes, they are processor instructions. For managed, they are MSIL instructions that the managed runtime in turn converts to processor instructions at JIT time. If your target is an ARM platform, you cannot use an x86 compiler. Broadly speaking, you need to use the correct Microsoft compiler that support Windows CE, and call that compiler with the proper switches to tell it not only the processor architecture, but also the target OS because the linking that needs to be done will be different for OS-level APIs and even the C runtimes. The short of this is that for your platform, you need to use Visual Studio 2008 Pro.
For native apps, you need some SDK that targets the same OS version (CE 6.0) and processor architecture (e.g. ARMv4I). Having it match the OS feature set is also useful but not a requirement. For managed code, you can just use the SDKs that ship with Studio because managed code is not processor-dependent. Still, you have to go back to Studio 2008 because 2010 doesn't have any WinCE compilers.
If you've found an existing library, then you can try to use it. Things that might impede your progress are A) it's unlikely to use an SDK you have so you probably have to create new project files (painful, but workable) and B) if it uses features not available in your OS, then you'd have to work around those. If you're missing OS features, you're probably out of luck but if it already has a media player and codec, I suspect you'll be ok.
Don't implement this in managed code. Seriously, just don't do it. Could you? Yes. Performance could probably be made to be nearly the same except to avoid GC stuttering you're going to have to basically create your own memory manager. The amount of work involved in this path is very, very large.
Are there any boost binaries available for Windows Phone 8? I'm mostly looking for the basic stuff such as shared_ptr and threading. Note that threading needs both to be build for ARM and use the correct platform calls, while shared_ptr works right of the bat.
If not, how do I build boost::thread for Windows Phone 8?
Update: I checked out the WinRT API and the boost source. The windows threading in boost relies heavily on Thread Local Storage (TLS), but this is not supported on WinRT. However, there seems to be some Fiber Local Storage (FLS), but it's not quite the same thing.
There is an official page on this dated of 18 Jul 2014, confirming that some of the libraries in Boost use APIs that aren’t available in Windows Store and Phone applications, and as so saying We’ve made improvements to the Boost build system to support targeting the Windows Runtime for Windows Store and Phone.
I'm compiling against some static libraries that rely on boost so I don't think that's an issue at all.
As of Visual Studio 2013 Update 4, you can compile source that uses the TLS APIs since they are implemented as inlines that forward to the FLS APIs (which are Store-compliant). Obviously pre-compiled binaries won't work since they will try and bind to TLS directly.
FYI the reason TLS is deprecated / banned is because there is the potential to leak memory if a thread terminates. If you use TLS APIs in Store apps they will have the same issue of potential memory leaks (the FlsCallback provided to FlsAlloc is null) so consider moving to TLS and providing a cleanup function.
This article (from the Windows engineering team) says:
WOA [Windows On ARM] will not support any type of virtualization or emulation approach,
and will not enable existing x86/64 applications to be ported or run.
Does that mean I won't even be able to recompile an x86/64 application from source for ARM?
If yes, what exactly prevents me from doing that? My understanding is that the Win32 API is present on Windows 8 ARM.
If no, what do they mean by not being able to port x86/64 applications to ARM?
From the Windows article you link to, the second quoted paragraph is the killer. Porting existing apps is definitely NOT supported.
Developers wishing to target WOA do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps. Code that uses only system or OS services from WinRT can be used within an app and distributed through the Windows Store for both WOA and x86/64. Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
If we enabled the broad porting of existing code we would fail to deliver on our commitment to longer battery life, predictable performance, and especially a reliable experience over time. The conventions used by today’s Windows apps do not necessarily provide this, whether it is background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques. By avoiding these constructs, WOA can deliver on a new level of customer satisfaction: your WOA PC will continue to perform well over time as apps are isolated from the system and each other, and you will remain in control of what additional software is running on your behalf, all while letting the capabilities of diverse hardware shine through.
Only a subset of Win32 is supported on Win8 for ARM:
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
If you try to build an application that uses a Win32 API that's not supported, it won't build because the API won't be in the library. If you try to create your own library to support the APIs, the application still won't be usable because the only way to deploy apps to customers will be through the MS app store, which will no doubt check for API conformance.
From The "Building Windows for the ARM processor architecture" article:
Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
It might be possible to do so on your development machine (but maybe not - I'm really not sure if such a 'hack' will be possible, supported or not), but you certainly won't be able to deploy it in any kind of widespread fashion.
In short, any existing Win32 application will likely need significant work to be ported to Win8 for ARM. It won't be a matter of recompile and fix any errors that pop out to get the application to run on ARM.
They do provide this caveat a little further in your cited article:
Additionally, developers with existing code, whether in C, C++, C#, Visual Basic, or JavaScript, are free to incorporate that code into their apps, so long as it targets the WinRT API set for Windows services.
They've got version of Office and IE available; I'm positive those weren't ground-up reimplementations.
Someone I used to work for emailed me out of the blue and said they want me to update a VB3 (!!!) program I wrote for them because customers are reporting having problems running it under Windows 7. They have lost the source code (natch). Is there a decompiler for VB3?
For decompiling VB "DoDi VB3 decompiler" is the best tool available. The results are pretty good.
However the original is anno 1997. VB3 is 16 bit code only + still some bugs + no source code. These makes that tool hard to get running on windows beyond Windows XP and limits it's use.
DoDi's VBDIS3 it self is also written in VB3 - so about 10 years later just for fun I cracked it to make the decompiler to decompile it self.
... and ported it to VB6!
So now you've the source code !!! :D
... and it's 32 Bit code + some bugfixes and improvements to the original:
DoDi's Visual Basic 3 Decompiler [Reloaded]:
http://vbdis4.angelfire.com
Screenshoot:
in case that website get lost Google for
'VBDIS3.67e_Reloaded_Rev3_DoDi_s_VB3Decompiler.7z'
or try the internet archive
http://web.archive.org/web/20090301170633/http://vbdis4.angelfire.com
I remember looking for Visual Basic decompilers/disassemblers a long time ago to no avail. There may be things out there now though. The most I could come up with was PE Explorer: http://www.heaventools.com/overview.htm
Have you suggested running your application under Windows Compatibility mode: http://www.sevenforums.com/tutorials/316-compatibility-mode.html
Edit: Further Googling: http://www.w7forums.com/visual-basic-3-0-compatible-64-bit-version-t5146.html
I maintain legacy 16-bit VB3 software
that is compatible with Windows 7 and
have done a lot of research in this
area.
16-bit applications will not natively
run in Windows 7 64-bit full stop.
This is because when a 64-bit capable
CPU is started in 64-bit mode, it
cannot change into 'real mode' (the
mode used by 16-bit applications)
without a hard reset. If a processor
is in 32-bit mode, it can swap between
real mode and protected mode at will.
The only workaround here is a virtual
machine- Windows 7 comes with a free
version of Windows XP which is usable
inside a custom version of Microsoft
Virtual PC. Google for "Windows 7
Virtual XP Mode". Once your copy of
Windows 7 has been validated as
authentic, it will allow you to
download Virtual PC and the XP Image.
It's definitely not a pretty solution,
but the only option for my customers
who have gone ahead and bought a
64-bit OS without checking to see if
their installed software is 64-bit
compatible.
Unlike the later versions which used native code and are generally not reliably decompilable, VB3 (and, I think, VB4) could be usually decompiled to almost original code. The keywords you need to search for are "DoDi VB3 decompiler" or "vb3dis". Here's a page that seems to have a copy.
Really? VB3, if it runs fine in XP, should be okay in the Windows compatibility box.
What I would do is to say that you couldn't find anything suitable (which is almost certainly true) but that you may be able to fix their problem for a moderate fee. Then, hopefully it's just a matter of setting a flag on the application (you may want to check this first to ensure it won't be too much work).
Money for Jam.
The other option is that you can offer to rewrite it for them in a more modern setting, using your vast knowledge of the application.
However, I'm surprised you don't have a copy lying around. I keep just about every piece of software I've ever written just in case (with permission for work-for-hire stuff of course), even down to the Fortran assignments I did at Uni back in the early 80s.
That's a good habit to get into, although I'm starting to wonder whether I should perhaps free up some space by ditching the Fortran :-)
There are a number of things you can do to help them without the source code. You could apply an external manifest if the application will only work when it is elevated. You could advise them to install the application somewhere other than Program Files (generally an awful idea, but might work in this case.) You could apply a compatibility setting or teach them how to install it into "XP mode" so it runs in an XP virtual machine.
Failing all of those, you could offer to rewrite it in VB.NET so they would get a more modern ui, Windows 7 features (not just capabilities) and would actually own the source code for their app. That might have value for them.
And yes, you should have kept the code. I have CDs burned from my old projects going back to the dawn of time (at some point I copied things from 3.5" backups to CDs while I still had some machines that could do both) and I have made more than one previous client happy by sending them the CD. It is a really cheap marketing investment, really.
It sounds like this is an application that is sold to customers, and is having trouble or doesn't work under Windows 7.
Consider advising the customer that the application should be:
modernized, thereby easing the ability to add features/maintained
otherwise run in XP Compatibility mode for their Windows 7 customers. Surely that number will only grow, and would become a support issue. Goto previous bullet.
Seriously though; your customer should realize that their software needs to be modernized. Hopefully you can persuade them of that long term goal; perhaps they already know that.
Have you used Windows 7 Embedded, what did you think of it, and are there advantages of using it vs. normal Windows 7 for a kiosk-type application?
The greater target reconfigurability probably makes it easier disable all the bits you don't want the end-user to mess with. There are a large number of users that will recognise that it is running Windows and then see it as a challenge to break it because they know all the keyboard short-cuts and legacy baggage and think they can break it (and they may not be wrong!).
A better question perhaps is whether there an advantage to using Windows anything as opposed to something else entirely, such as QNX Neutrino or Linux. You could even use Chrome OS
This article considers Kiosk operating systems and specifically considers Consumer Windows vs Embedded Windows.
Windows Embedded provided several drivers that aren't in the standard Windows distribution that allow you to run off of a read-only medium or to finely control what modifications can be made to a writable medium (including the boot partition or registry). These can help ensure that when your device powers on or resets, it'll be in a 'factory clean' state or that any modifications are strictly due to intended updates or specific configuration data These features can be quite important in dedicated devices.
Also, Windows Embedded contains a rich toolset to configure the OS to contain only the components that your application requires. If nothing else, this will likely make the system a bit more secure or resistant to non-essential bits from interfering with the dedicated purpose of the kiosk/device.
I'm not sure what the licensing differences are between Windows Embedded and the normal desktop Windows software, but I'd expect that Windows Embedded licensing would be more in line with what that market would require.