Here is the situation:
App: C# Platform: X86
DLL: C++ Platform: WIN32
Test1:
(Rugged Tablet PC) with: Windows Embedded 8 Pro
32-bit Operating System, x64-based processor
The app runs fine, but the call to the DLL crash.
Test2:
(Rugged Tablet PC) with: Windows 8 Pro
32-bit Operating System, x86-based processor
All OK! App and call to DLL are fine.
Thank you for helping me to figure what is going on. What is it crashing in Test1?
Thanks.
Windows 8 Embedded is customized to not include all the features that the full version has. This means less stuff running in the background, and less files that may need security updates.
But it also means if you try to use those features you will fail. The exception message should give you information about what was missing. I suggest that you log the exception information, to help you troubleshoot or work around the issue.
The included set of features is fully customizable, so you will need to contact whoever you got the tablet from in order to determine everything that is missing.
Related
I currently have a 32-bit PowerBuilder application that we are trying to port over to a Windows 7 64-bit environment. Realizing the obvious that PowerBuilder 10.5 was built previously before Window7 came out and the big also the obvious fact that this application was built within a Windows XP 32-bit environment.
The 32-bit PowerBuilder application spits out the following error message when deployed on a Windows 7 64-bit machine.
Application Terminated. Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow
The database profile setup points to an OLEDB and the backend database is MSSQL 2008. Currently the application does run on the Windows7 64-bit environment and seems to be working in an inquiry mode only. Meaning we can read some of the records on the datawindow, but as soon as you try to make a transaction it blows up.
My question is - Is it possible to get a 32-bit app working in a 64-bit environment?
So far the client is asking to come up with possible solutions without the idea of upgrading to PowerBuilder 12.5. Essentially they want to stay at 10.5 but yet get the app working from a 32-bit environment to a 64-bit...apples to oranges if you know what I mean. Further investigation is needed into whether the code will not function in 64bit or dll issues with powerbuilder client runtime in 64bit. They are really trying to stay away from any app rewrite since the application is older than when Christ was a carpenter. The app was originally built in PB 6.5 I think.
So far I have the following ideas but I am new to this:
- I understand that Windows 7 comes with a virtual machine IIRC. I think it's called WOW64. Is it possible to create a virtual on a server and have the users run a 32-bit application inside a 64-bit machine? Then create a shortcut of somekind for the user to simply click on?
We do have a virtual XP machine and a virtual Windows7 64 bit machine for testing. PowerBuilder 10.5 actually installed on Windows 7 and seems to be working fine. However running the application in run mode or debug causes many errors as you can imagine.
The application has been built in XP and run on Windows 7, but the results yeild the above error message.
I have not looked yet into the Run under Compatibility mode, but I am told by the team it will not work.
I have not looked at UAC or ALC User management yet. Could that be something affecting the 64-bit system?
I know this is app unrelated but...I have seen in some cases 32-bit applications work in a windows 64-bit environment by simply targeting certain DLL files. An example case is Microsoft Flight Simulator X where the 32-bit game would crash in windows 7 64-bit. The solution for that was to simply go get a Vista 64-bit DLL file called uiautomationcore.dll and copy that into the windows environment. The Games also have to be installed on the root of C: in order to work.
Does anyone have any recommendations on how I can approach this problem?
I apologize If I'm vague in my notes here.
UPDATE: Has anyone had any experience with PB 10.5 runtime files on a 64 bit machine? I am wondering if the powerbuilder client runtime is installing its dlls into the correct location of the application C:\XXX or can't find it? Wondering how to approach this.
Basically nothing should prevent a 10.5 PB app to run on Win7/64. I develop and run several products in PB11.5 (also a 32bit IDE) on a win7/64. And btw, some older PB like 9 still run on Win7, so is likely PB6.5. The problem must be elsewhere, relative to the app design.
WoW64 (and Wow6432Node in the registry) is not a true VM, it's a bunch of services and system API hooked with fallbacks for 32 bit applications (and legacy applications that do not conform to the novelties introduced since Vista)
Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow sounds typically like an incorrectly handled return value (where a computed row number is getting negative or null before trying to access a property or data at that given invalid row), or it could be relative to the way to get back an autoincrement value from the db after an insert
beware of the UAC management that could lead to unexpected behavior with legacy application, especially if the application is using a database: the UAC guidelines tells not to install data managed by the application in the Program Files folder that is now Read only (since Vista - that guideline is since XP). Instead you must put that into a ProgramData sub-directory if it is accessible by everyone and into a user local AppData if the data is just for the current user. Win7/Vista can silently conforms to the standard by duplicating the data locally to the user (in the Users\username\AppData\Local\VirtualStore) while still pretending to the application that it is currently accessing it from Program Files...
you could give a try with Dependency Walker to look for the incorrect dll problems
We moved many of our applications to Windows 7 64bit. The only issue we ran into was with the database connections. You are running a 32bit application so you need to connect to 32bit database. If you bring up "Data Sources (ODBC)" from the control panel, you will be looking at the 64 bit entries. You need to use the 32 bit ODBC found in "C:\Windows\SysWOW64\odbcad32.exe". The Registry entries you need are in the following locations...
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
or
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
Before I ask my question, here's some background information so that you might have a better understanding of what I am trying to accomplish. I have searched around and found similar questions but none that are specifically what I am asking.
I am trying to port over a modified 32-bit PLX Pci9056 device driver to 64-bit. I also have a few User apps that utilize the driver. PLX provides a complete SDK, including the PLX API in a dll, driver source code, and tools to create and debug user apps. It uses the Windows DDK build environment to build the drivers. The following is how they all interact:
User app --> PLX API --> PLX Pci 9056 driver --> PLX chip
The 32-bit driver has been tested on Windows 7 32-bit and works properly. I believe I should be able to simply rebuild the driver in the 64-bit Windows DDK build environment (Of course after handling any pointer casting. Please correct me if I am wrong.) At this point the driver should run properly on a 64-bit Windows 7 machine.
I understand that usually 32-bit apps will run fine on a 64 bit machine, but in this case the User app is using the PLX API which was initially built only to support 32-bit. Will my User app still work in a 64-bit OS without updating it, or will I run into issues?
The PLX PCI SDK (now Broadcom PCI/PCIe SDK) has supported both 32b/64b drivers with the same source code for many years now. Special macros are used when required, etc. In Windows, your 32-bit app will work fine due to WOW layer. The PLX IOCTL structures always store pointers in 64-bit fields to ensure the structure does not vary if you build a 32-bit app. The SDK also provides 64-bit build of the API library, so you can also build your app as native 64-bit. The same app level source code, for the most part, should work in both Windows & Linux. The samples provided in the SDK are all identical source for both Win/Linux.
When developing an application for Windows Phone 8 on ARM, is there a way to simulate or emulate the app if it has ARM NEON assembly? I.e., is the code compiled for x86 and run natively, or is it there a way to actually emulate an ARM NEON machine?
The Windows Phone 8 emulator is an x86 environment, so ARM code isn't going to work.
There's no emulator, but there's a free remote device access service, courtesy of Nokia, at http://rda.cellulardata.com/devices . You can't debug, but you can watch it run. Bake in some visible reporting into your app, publish it as a beta, download to a device and enjoy.
Since it's a beta, it won't be available via store search; you'd have to type in a URL. A link shortening service or a forward page on your own web space would come in handy here.
You have to explicitly designate your own Live ID as a beta tester account for a beta project. The Store doesn't recognize the "I'm downloading my own app" situation.
...let me add that the Phone devices are still ARM, so if you want to run on both device and emulator, you'll need to compile your native code for both ARM and x86.
Is it possible to manually edit the driver to make it function on windows XP?
I guess there are many differences, but it must be possible for simple drivers, kind of porting the locations / buses they use?
Do you mean without re-compilation? If so its not recommended.
If you are willing to compile then use appropriate WDK and select appropriate build environment and try to build. You may have to change the code depending upon any APIs changed/availability.
Also note that drivers are compiled per OS i.e. there are different build environments for WinXP, Windows 2003, Windows Vista, Windows 7 etc.
I've got a driver for a custom PCI card, which builds and runs fine on XP. I'm trying to use this custom hardware on W7, and am trying to build and run my driver.
I've got the latest DDK from Microsoft, and build my driver for XP using Windows XP "x86 Free Build Environment". Everything installs & works fine. (Build using a DDK "build" command)
If I use the Windows 7 "x86 Free Build Environment" build environment, everything builds fine. I run it through the PREfast and staticdv code checkers, no errors from either. ( I get a couple of warnings about "The dispatch function 'FooFnc' does not have any __drv_dispatchType annotations" - are these likely to be the issue? )
When I install, the install starts OK (standard error about drivers not being signed), but gets to a certain point and then hangs, then fails with a timeout error. The device then shows up in device manager as installed. At this point the PC won't shutdown or boot, but hangs indefinitely. I'm forced to boot into Safe Mode and uninstall the driver from there.
So my question(s) are:
If there has been a change in the driver model between XP and W7, what's the best way to find it? I can't see anything on MSDN.
How would I go about debugging the driver? The box doesn't start, so it's not like I can run up WinDBG.
Any specific W7 driver gotchas that are hidden away?
I've tried to keep this as generic as possible, but if more detail would be helpful I'll provide more
AFAIK, the biggest changes have been made in video and network drivers. Other drivers retain backward compatibility and can be run on W7 even with no recompiling.
Run your driver under driver verifier and turn on generating crash dumps with a keyboard (very helpful in case of system hangs, you can manually generate crashdump, analyze it and find what was wrong).
Hope this helps!