Anyone have experience with OPOS? I can't get my app to recognize the LDNs for the devices running on a 64 bit machine.
I've got down to the point where I know that the OleforRetail stuff is now under Wow6432Node in the Registry. I suspect the common controls can't find the LDN because of this. Is there any kind of workaround?
Failing that, is there a centralized OPOS development forum somewhere?
BTW: I work with the common controls supplied by Monroe Consulting.
Thanks!
What are you using to develop your application?
If you are using .NET you need to set it to be compiled as a 32-bit version.
Platform target: x86 on the c# project settings.
If a program is 32 bit or 64 bit decides where in the registry it looks for values.
All the OPOS com objects are 32-bit, so if you use a 64-bit program it will not find any information about them.
The biggest problem that I had is that the LDNs weren't being found by my app. Well it turns out that you have to run the OPOS driver configuration software as administrator to get it to manipulate the 32 bit section of the registry properly. The LDNs just weren't being written in the right place in the registry so my app couldn't find them.
Related
I was trying to follow the the installation tutorial of the Native Client SDK found here. However, my Samsung Chromebook (in developer mode) does not want to run ./naclsdk (chmod +x done), but instead returns the following:
32-bit runtime environment was not found on this
system. Specifically the 32-bit dynamic loader which is needed by the NaCl
compilers was not found ('/lib/ld-linux.so.2'). On modern debian/ubuntu
systems this is included in the 'libc6:i386' package.
On here they write that the PNaCl should run on ARM computers, however, on some other forums I read that wasn't the case. I've tried enabling two flags, as described on a site which I can't post due to a lack of reputation, but it looks like that'll only change things when using PNaCl, not during the installation of the SDK.
Is it possible to install that SDK on my Chromebook and, if so, how?
There's a bit of confusion: when the documentation says "PNaCl and NaCl work on ARM", it means the part that runs inside of Chrome which users would use. The SDK is currently only built for x86-64 Windows/Linux/OSX, and not for ARM. The main reason is that it's never been requested, probably because ARM machines are quite slow compared to usual development machines.
That being said, I don't think it's silly to use ARM as a development machine, and I've built my own PNaCl toolchain for ARM in the past. There are build instructions for the toolchain. I haven't built it recently, and it may have bitrotted a bit so if you run into issues I suggest emailing the team or better yet sending a patch! I expect any issue to be fairly minor, especially if you only want to use pnacl-clang or nacl-clang (as opposed to the GCC toolchain).
I am trying to implement a virtual camera application in Visual C++ for 64 bit Windows. I started with the code here: tmhare.mvps.org/downloads/vcam.zip which emulates a video capture device using DirectShow filters. It works fine for me on 32 bit windows, but doesn't work on 64 bit windows. I modified the Visual C++ project as follows:
1) changed the platform to x64 and recompiled the dll, linking in the 64-bit version of strmbase.lib
2) changed preprocessor definitions to WIN64,_WIN64 from WIN32,_WIN32;
3) Recompiled the library and registered the dll using C:\Windows\system32\regsvr32.exe
The dll registers successfully and regedit shows three keys for my virtual camera in
HKEY_CLASSES_ROOT\CLSID\{860BB310-5D01-11D0-BD3B-00A0C911CE86}\Instance\{8E14549A-DB61-4309-AFA1-3578E927E933},
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{860BB310-5D01-11D0-BD3B-00A0C911CE86}\Instance\{8E14549A-DB61-4309-AFA1-3578E927E933},
HKEY_CLASSES_ROOT\CLSID\{8E14549A-DB61-4309-AFA1-3578E927E933}\InprocServer32
However, neither Skype nor Windows Live Messenger see the camera on 64-bit windows.
What am I doing wrong? I understand that Win64 has HKEY_LOCAL_MACHINE\Software\Classes\CLSID{guid} for 64-bit applications and HKEY_LOCAL_MACHINE\Software\Wow6432Node for 32-bit applications, but since I am compiling my code as a 64-bit application, it seems to me that its keys are being placed in the right part of the registry. Is there a DirectShow virtual camera filter implementation for 64-bit windows I could use as a sample (I only found one for 32-bit windows)?
I tried out DirectShow a year or so back, and from what I can remember, there isn't support for it in 64-bit applications. So I'd recommend either switching to 32-bit mode, or finding a library which supports 64-bit. This may help you.
http://directshownet.sourceforge.net/
64-bit filters work exactly as their 32-bit peers, no specificity involved. A general rule applies, which is worth mentioning: filter DLL bitness should match the application bitness, e.g. as Skype is always 32-bit regardless of OS bitness, you need 32-bit virtual camera for it. Skype just does not care about 64-bit filters as it never uses them.
Also, I don't understand your #2 above. You only need to create duplicate existing configuration for another target (x64) and visual Studio will update predefined conditionals such _WIN64, no manual changes required in code.
I want to make a registry filter driver specifically for Windows XP.
I know there is an example in the official WinDDK but it only works
on Windows 7.
Is it even possible to develop a registry filter driver for windows xp ?
Any kind of code/pointers will be highly appreciated.
You can also hook the registry API functions using Microsoft Detours (or similar package). This is no easy task to get correct (still finding the bugs) but if you are up for writing drivers then this is no different in complexity. Just less blue screens. Look at hooking the Nt or Zw functions in ntdll.
No this is not possible. For Windows XP you need to hack the kernel API table. This is not recommended, but for windows XP it is the only option. This is how the Sysinternals RegMon program used to work.
Yes, it is possible altought I would not recommend it.
First, you have to hook SSDT. Please notice that hooking SSDT is not supported in XP 64 bits (Patch Guard), you have to understand what are you doing (BSOD hook), is not portable and your software can be marked as malware.
Second, you need to do reverse engineering of Key Control Blocks. When two different apps open the same key, they get two different handles but they KCB is unique for both threads. KCB is an opaque structure so WinDbg is your friend here.
Our development environment is all 32 bit, but our production SharePoint farms are all 64 bit. Can we just deploy the SharePoint solutions straight to the 64 bit platform, or do we need to recompile everything?
If you have the Platform Target set to "Any CPU" (which is the default) then you do not need to recompile. You can find this drop-down by going to the Build tab in the project properties. The .NET Framework is smart enough to adjust to either platform when this setting is enabled.
I'm working in the same environment that you describe with these settings and have no issues.
Edit: A good question that describes this further - Compile ASP.NET to 64 BIT.
Slightly offtopic, but if you deliver your solution files through MSI's build as a simple Visual Studio Setup Project, like we do, that's a different story. Those MSI's are 32 bits, and require a fair bit of modding to make them 64 bits compatible.
The solutions themselves, however, should pose no problem whatsoever.
We are getting new dev machines and moving up to Vista 64 Ultimate to take advantage of our 8gb ram. Our manager wants us to do all dev in 32bit virtual machines to make sure there will be no problems with our code moving into production.
Is there any way to guarantee the resultant programs will work on 32bit os's?
I don't mind using virtual machines, but I don't like how they force you back into a "Single" monitor type view. I like moving my VS toolbars off to my other monitor.
EDIT: We are using Visual Studio 2005 and 2008, VB.NET and/or C#
EDIT: Using Harpreet's answer, these are the steps I used to set my Visual Studio IDE to compile x86 / 32bit:
Click Build and open Configuration Manager
Select Active Solution Platform drop down list
Select x86 if it is in the list and skip to step 5, if not Select <New...>
In the New Solution Platform dialog, select x86 and press OK
Verify the selected platform for all of your projects is x86
Click Close.
Enjoy.
Thank you,
Keith
I do development on 64 bit machines for 32 bit Windows. It's not a problem. You should make sure that your projects are set to compile in x86 mode in order to be conservative. You'll want to go through each project in the solution and double check this. You could also use the AnyCPU setting but that's a little riskier since it will run differently on your dev machine than a 32 bit machine. You want to avoid the 64bit mode, of course.
The problems I've run into are drivers that don't work when the app is compiled for 64 bit (explicitly 64 bit or AnyCPU compiled and running on 64 bit Windows). Those problems are completely avoidable by sticking with x86 compilation. That should reveal all flaws on your dev machines.
Ideally, you could set up a build and test environment that could be executed against frequently on a 32 bit machine. That should reassure your management and let you avoid the VM as your desktop.
As long as you compile your executables as 32 bit, they will run on both 32 bit and 64 Windows machines (guaranteed). Using 64 dev machines has the advantage that you can start testing your code with 64 bit compilation (to check for things like pointers casted to 32 bit integers), this way making the transition to 64 bit easier in the future (should you your company choose to do a 64 bit version).
Compiling for a 64bit OS is an option in the compiler. You can absolutely compile to a 32bit exe from within Vista 64 bit. When you run the app, you can then see in the TaskManager that there is a "*32" next to the process...this means it's 32bit ;)
I believe your managers need some more education on what 64bit OS really means :)
Not an answer to your question, but possibly a solution to your problem: VirtualBox (and probably others) supports "seamless integration" mode, which just gives you a second start bar and lets you drag windows around freely.
Also, and this is an answer to your question, it depends on your compile settings. You can compile for different environments, and you can perfectly compile 32-bit programs on a 64-bit system with Visual Studio. Can't tell you how, but I'm sure some Visual Studio guru could help you out.
We develop a 32-bit application using VS 2005 (2008 soon) and have just purchased some new machines with XP Pro x64 or Vista Business 64-bit on them so that we can take advantage of the extra RAM whilst holding a watching brief on the possibility of doing a 64-bit port if it becomes commercially necessary to do so. We haven't had any problems with doing this other than tweaking some scripts in our development environment etc.
Those developers who weren't included in this upgrade cycle still use 32-bit machines, so these should pick up problems when the unit tests and the application test suite are run as a matter of course before a check-in.
What we also do is to make sure that we have a set of "test build" machines made up of "typical" configurations (XP/Vista, 2/4/8 cores, etc.) that build and test sets of check-ins - we have various different test suites for stability, performance, etc. - before they are added to the integration area proper. Again, these haven't picked up any problems with running a 32-bit application built on a 64-bit OS.
Anyway, as others have already said, I wouldn't expect it to be a problem because it's the compiler that generates the appropriate code for the target OS regardless of the OS that the compiler is actually running on.
yeah, like adam was saying. There's 3 options: MSIL (default), x64, and x86. You can target x64 and it will generate dll's specifically for 64-bit systems, or you can do x86 which will run on 32-bit and 64-bit, but will have the same restrictions as 32-bit on a 64-bit system.
MSIL will basically let the JITer issue the platform specific instruction (at a slight performance penalty compared to a native image)
EDIT: no language, so i'm talking about .net framework languages like vb.net and c#, c++ is a completely different animal.
Found this today:
http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx
x64 Development with .NET
Earlier this year I made the switch to a 64-bit operating system - Vista Ultimate x64 to be exact. For the most part, this process has been relatively painless, but there have been a few hiccups along the way (x64 compatible drivers, mainly, but that's not the point of this discussion).
In the world of x64 development, there have been a few struggling points that I thought I'd outline here. This list will likely grow, so expect future posts on the matter.
In the wonderful world of .NET development, applications and assemblies can be compiled to target various platforms. By default, applications and assemblies are compiled as Any CPU in Visual Studio. In this scenario, the CLR will load the assembly as whatever the default target is for the machine it is being executed on. For example, when running an executable on an x64 machine, it will be run as a 64-bit process.
Visual Studio also provides for 3 specific platform targets: x86, x64 and Itanium (IA-64). When building an executable as a specific target, it will be loaded as a process of that type. For example, an x86-targeted executable run on an x64 machine will run as a 32-bit process using the 32-bit CLR and WOW64 layer. When assemblies are loaded at runtime, they can only be loaded by a process if their target matches that of the hosting process, or it is compiled as Any CPU. For example, if x64 were set as the target for an assembly, it can only be loaded by an x64 process.
This has come into play in a few scenarios for me:
XNA - XNA is available as a set of 32-bit assemblies only. Therefore, when referencing the XNA assemblies, the executable/assembly using them must be targeted to the x86 platform. If it is targeted as x64 (or as Any CPU and run on a 64-bit machine), an error will be thrown when trying to load the XNA assemblies.
Microsoft Robotics Studio - The XInputGamepadService uses XNA internally to talk to the Xbox 360 controller. See above.
Managed DirectX - While this is already deprecated and being replaced with XNA, it still has its uses. The assemblies are not marked for a specific target, however I had difficulty with memory exceptions, especially with the Microsoft.DirectX.AudioVideoPlayback assembly.
Phidgets - Depending on what library you download and when, it may or may not be marked as 32-bit only. The current version (11/8/07) is marked as such, and so requires a 32-bit process to host it.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.