We are developing WIFI miniport driver for Windows Embedded Compat 7. Plan is to extend the security features supported by Native 80211 framework through IHV Extensions DLL. But didn't find any resource specifying WEC 7 support for IHV Extensions Dll.
Pls let us know whether WEC 7 supports it and any resource for developing. Thanks in advance
Related
Please can anyone tell me if it's possible to statically link in all the directx libs.
Basically can i build an exe that will run on any windows system that does not have the directx redistribu installed?
As noted, you can't statically link the "DirectX" libraries i.e. Direct3D, DirectInput, DirectSound, etc. That said, depending exactly on your definition of "any Windows system" you actually do not need the DirectX "Redist". It doesn't do what you think it does. See Not So DirectSetup for the a longer discussion of this.
If you use Direct3D 9 or later, DirectDraw, DirectSound 8, DirectInput 8, DirectShow, DirectMusic, DirectPlay, etc. i.e. what historically has been called "DirectX 9.0c" (aka the Summer 2004 release), those bits are always present on Windows starting with Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, and Windows XP x64 Edition. Therefore, as long as you require those as your minimum OS (or something greater), you don't need any DirectX Redist because it doesn't actually install any of those things. Take a look at What's in a version number? for examples of the "you must be this high to ride this ride" checks that guarantee this. Supporting Windows 2000, Windows 9x, or Windows ME or even Windows XP RTM/SP1 these days seems way out of scope.
For Direct3D 11, read Direct3D 11 Deployment for Game Developers. Direct3D 11.0 is built into Windows 8.x and Windows 7. It is on Windows Vista Service Pack 2 with KB 971644 installed which was pushed by Windows Update so it's basically everywhere.
Where it gets murky is if you are using other stuff in the DirectX SDK:
All versions of D3DX9, D3DX10, and D3DX11 are deprecated (see MSDN). If you depend on these, you still need the legacy DirectSetup. The good news is that with Direct3D 11, you don't need to use it at all. Instead see Living without D3DX for a bunch of new support libraries that are statically linked to your application as well as available shared-source--which includes DirectX Tool Kit mentioned in the other answer.
The HLSL compiler is not actually in D3DX anymore, and if you use the Windows 8.x SDK version of D3DCompile you can deploy that DLL side-by-side with your application avoiding the need for the DirectX Redist. See HLSL, FXC, and D3DCompile. Note that this DLL only supports Windows Vista or later, so runtime HLSL compilation on Windows XP still requires the legacy DirectX SDK and DirectX Redist. If you pre-build your shaders and are not using the Effects (FX) framework, this is not an issue.
If you use XINPUT, you should use XINPUT 9.1.0 (the original version) unless you are specifically using the headset audio features of XInput 1.3. This version is built into Windows Vista and later. If you require Windows 8.0 or later, you can use XInput 1.4. See XINPUT and Windows 8. Note that Server editions of Windows do not have XInput 9.1.0 or 1.4.
If you are using XAUDIO2, then you have a choice to make. If you require Windows 8.0 or later, then you can use XAudio 2.8 as it's built-in to the OS. Otherwise you need to use XAudio 2.7 which still requires the legacy DirectX REDIST to deploy. See XAudio2 and Windows 8.
If you use XACT, then you have to use the legacy DirectX REDIST as that's the only way to deploy the XACT engine.
If you are using the legacy DirectX Managed Assemblies for .NET 1.1, you should move to something else like SlimDX or SharpDX for a host of reasons. See DirectX and .NET
If you are making use of other "DirectX" things, you should read DirectX SDKs of a certain age for some guidance. In short: Don't use Direct3D Retained Mode, DirectPlay Voice, or DirectX 7/8 Visual Basic 6.0 as they aren't in the OS starting with Windows Vista.
No, the DirectX redist binaries are not available as static libs, though most of the useful functionality is now available as source in the DirectX Tool Kit.
I am an IT engineering student and I am currently working on embedded system project and I want to know if Phidget SBC supports Windows Embedded because in the product specifications I found that its default OS is Debian Linux. If it is possible, does Phidget SBC3 run Windows Embedded 8/Windows Embedded 8.1 ? Thank you.
The Wikipedia entry about Windows 8 claims in its Metro section that
Metro applications will be cross-compatible with both x86/64 based
systems and Windows on ARM.
but does not have a reference (it is marked with "citation needed").
Technically, would it be possible to run a "native" Metro app which was build using WinRT for x86/64 on ARM?
Yes, Metro apps are specifically stated as the supported method for doing cross platform apps on both Windows 8 and WOA (Windows on ARM). Full details are in this blog post. The post also states that other types of applications that run in Desktop mode in x86 Windows 8 are specifically not supported on WOA (some Microsoft apps being the sole exceptions).
A JS app should work on ARM unmodified. I'm not 100% sure about C#, an app written for "any CPU" should just work on ARM (but I've not confirmed). C++ applications will work, but will need to be recompiled specially for ARM.
I need to install the Windows Embedded CE 6.0 package that works with Visual Studio 2005 because I need to upgrade an old driver that runs under CE 6.0. I understand that Microsoft does not support this CE package any longer and, in fact, they no longer provide the installation files for CE 6.0
Where can I get the Windows Embedded CE 6.0 installation files??? They can be in an ISO file or whatever format is available.
I'm not sure if I understood your question right. By package you mean BSP (Board Support Package)?
If you are new to CE, you will need a brief explanation before get started.
The Windows CE 6.0 itself doesn't have exactly installation files. The runtime system is built through a toolkit called Platform Builder. As "input" for platform builder, you select which components your runtime image will have (including drivers) and as "output" is created a binary image of your system. You may transfer your runtime image to the device with a few different methods.
Regarding drivers, they usually are distributed through BSPs. BSPs are built by the device maker so you could check the device manufacturer site for BSPs, but you can give a try first on the supported packages search (http://www.microsoft.com/windowsembedded/en-us/downloads/board-support-packages-for-windows-embedded.aspx).
You can get the Platform Builder Toolkit with a Microsoft Authorized Embedded Distributor or through a MSDN subscription (http://www.microsoft.com/windowsembedded/en-us/evaluate/how-to-buy-windows-embedded-compact-7.aspx). The Platform Builder for CE6 comes with a copy of VS2005.
Windows CE6 is currently at R3 (released in 2009) and it is supported (mainstream support) at least until 2014 (http://www.microsoft.com/windowsembedded/en-us/evaluate/windows-embedded-roadmap.aspx).
I strongly recommend you to take a look at least on http://www.microsoft.com/windowsembedded/en-us/develop/windows-embedded-ce-6-for-developers-overview.aspx. I'm not much experienced with CE6 (few months) but my personal experience says that it's a long path to code drivers for CE.
I installed Microsoft Speech Platform SDK 10.2, and I notice that sapi.dll and mssps.dll have similar APIs. What's the difference between them? Which one should I use? Thanks.
Microsoft Speech Platform SDK 10.2 is the server version of SAPI. The server engines support lower quality audio, but don't support dictation. Also, the server versions of SAPI (I believe) have license restrictions that the desktop versions do not.
The desktop engines are typically bundled with Windows, so if you have Vista or Windows 7, the desktop engine is built in; for XP, the desktop engine is free to use.