Hi!
I have an old plugin (as binary, dll), used by my application. It was build for WM2003. And now it crashes the app, if loaded on Windows Mobile 6.1 (WM5 works fine, WM6 too).
The source code is not available and it's no more supported by developer. So I can't rebuild it for WM6.1.
Is it possible to patch or convert the binary to allow it to work on WM6.1 ? If so, how can I do this ?
Thank you.
Edit: I've found, that the problem is in PE loader, which acts not the same on WM6.1 (comparing with WM6 and earlier).
Does this plug-in use MFC or ATL? Earlier versions of WinMo had a different ATL/MFC version baked in, so MFC or ATL apps written in Studio will not work unless you deploy the newer ATL/MFC libraries along with the app, just as the old apps will not work on new devices unless you deploy the old MFC/ATL libraries.
This problem is rare, but some information can be found.
The common solution is to rebuild a binary in VS2008 (TCPMP new VS2008 builds for WM6.1), but this will not help, if you don't have the source code.
I've found the problem explanation and another solution in cegcc mailing list (arm-wince-cegcc on Windows Mobile 6.1). In Windows Mobile 6.1 Memory Management scheme was changes.
This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0. However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space.
In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot. Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks. ...
And the workaround for this issue is to declare the DLL in registry (to tell the OS not to load it in high memory).
I don't like this workaround, so I try to find some binary patcher. And found it :)
It's not really a patcher, it's UPX - the Ultimate Packer for eXecutables. But it solves the problem perfectly. The DLL, packed with UPX don't crashes the application and runs fine.
Related
I want to run IOS Simulator on Windows 10.
Is there a way to do this?
I dont think its possible to get the iOS simulator working on Windows. But if you are willing to explore a dual boot setup, have patience (and a supported motherboard/processor), then you could use OpenCore or Clover to get a macOS running on your pc. This will give you access to the iOS simulator and the other xcode tools.
If you take this route then you should know that macOS doesnt support ntfs writes out the box. This means that if you decide to create a shared volume that both the mac and windows partition would read and write from, then you would either need a 3rd party ntfs drive (e.g. macfuse) or to format your volume to exFAT (this gave me the best results and was free)
If you intend to run the latest macOS I would recommend going with OpenCore. The latest Clover versions ports pieces of OpenCore to it, and finding documentation on configuring the new Clover was a hassle for me. If you are fine with running Catalina and using an older xcode (and thus older iOS simulator), then I would recommend giving tonymac tools a shot. Building the installer took with very little effort. You need an account to download the tools (this is free but they ask for motherboard/gpu model for community posts and verification that you can actually run their software)
Native testing of iOS apps is only possible on an Apple device. But there are some ways to overcome that.
Some reference to external iOS simulating platforms: https://fossbytes.com/best-ios-emulators-pc-windows-mac/
I have my processing code in dev/processing and my Arduino code put itself in Documents/Arduino.
However, whenever I get into one environment, it changes the most recent directory for the other because Arduino is written in processing.
Is there any quick way to disconnect the two environments so that they don't use the same location for "most recent directory?" I don't know whether the mechanism is a file, a registry entry or what, but I'm on Windows 8.1
I am using both Arduino IDE as well as Processing 2.1.2 in Windows 7 environment. It doesn't change the directory.
Since you are using Windows 8.1 (which is recently released), you may face very weird problems as those softwares are not tested on those OS. You will find errors for even other softwares that are designed before Windows 8.
When I create a new OS X application project, I noticed many target options those confuse me quite a lot:
(1) The top-left setting of Xcode window:
(2) The "Base SDK":
(3) "Deployment Target":
(4) Architectures:
Here comes my questions:
For (2) and (3), I think it was clearer to understand. These are what I comprehend:
(2) This identifies what I develop with.
(3) This identifies what OS version my application will be used on.
Please tell me whether I am right...
But I could not understand (1). I just know that if I select 32-bit here, I could not use ARC.
Neither with (4), what are they? Are they represent the bit-width of the CPU? What was the difference between (1) and (4)?
I'll explain your items out of order.
The Base SDK
This defines the largest set of APIs you can use. You can use anything that existed as of the version number identified here. For example, if you use the 10.8 SDK, you can use -[NSColor CGColor] (introduced in 10.8), but not -[NSData base64EncodedDataWithOptions:] (first public in 10.9).
(Of course, you can also use anything older than that version.)
Accordingly, the SDK version is also known as the “max[imum] allowed” version in the Availability macros.
The SDK version also sometimes becomes important when Apple changes the behavior of an API. When they do that, they sometimes keep the old behavior around for applications linked with older SDKs. This is called an “on-or-after check”, as in “checks whether you're on 10.8 [SDK] or later”. (The concept and term pre-date Xcode having SDKs for each OS version. It used to just go by whatever OS you were running Xcode and building on.)
The Deployment Target
This is the minimum OS version you require. If something was removed in a prior version (rare, but it happens), you can't use it.
This tends to affect link-time and run-time things more than compile-time things. For example, ARC won't work if your deployment target is 10.5 or earlier.
Accordingly, the Deployment Target is also known as the “min[imum] required” version in the Availability macros.
The Info.plist can also specify a minimum OS version. Nowadays, this is set by default and it's set by macro expansion to the Deployment Target.
The Architectures build setting
Different CPUs have different architectures. Essentially, they fit into broad categories, such as:
PowerPC 32-bit (ppc)
PowerPC 64-bit (ppc64)
Intel 32-bit (i386)
Intel 64-bit (x86_64)
ARM 32-bit
ARM 64-bit
(PowerPC architectures aren't supported anymore. You can add them to the Architectures list, as ppc and ppc64, but Xcode will just ignore them.)
Macs nowadays have Intel processors. Almost all Intel Macs have 64-bit processors. You only need to worry about 32-bit Intel if you want to support Macs all the way back to 2006. That's probably more hassle than it's worth.
iOS devices run ARM processors, and most are still 32-bit. The A7 (iPhone 5S, iPad Air, iPad Mini with Retina Display) is 64-bit. But, if you run on an iOS Simulator, it's running on your Mac (it's a Simulator, not an emulator), so it'll target an Intel architecture (formerly always i386, but probably can now be x86_64 if needed).
The “top-left setting of Xcode window”
This is the build scheme and run destination. (Yes, it's two separate things in one pop-up menu. Actually, it's two separate pop-up menus in one control. Try it.)
“My Mac 64-bit” is the run destination. You'll be running the 64-bit version of your app on your Mac, not in an iOS Simulator or on an iOS device. Your choice for a Mac app is merely which architecture you want to run, and they should behave the same (this is, obviously, something you sometimes need to test).
iOS apps have more choices here. Some apps are iPhone-only, some are iPad-only, some are universal, and some may be set to build for both 32-bit and 64-bit architectures. You'll have a Simulator offered for each combination of form factor and architecture (e.g., iPhone Simulator 64-bit) you can run on. You'll also have the option to run your app on any iOS device that's connected and enabled for development (you get this prompt when you plug in the device in Xcode's sight).
TL;DR
Deployment Target is the lowest OS version your app will run on.
Base SDK is the highest OS version you can use stuff from. If it didn't exist yet, it doesn't exist at all for you.
Architectures are the set of hardware your app will run on.
Run Destination is the hardware you're going to run it on from within Xcode.
Just like with most OSes these days you can develop either a 32bit or a 64bit application. The "bitness" refers mostly to how memory addresses are structured (either using 32bit allowing so at most 4GB to address or 64bit (computation left as an exercise to the reader)). However the choosen architecture usually has more implications (like the missing ARC support for 32bit apps) but also how wide CPU registers are, how much memory a structure uses in RAM etc.
OS X also supports socalled fat binaryies that is, a bundle containing both 32bit and 64bit variants of your application. This is however only needed if you normally prefer to run 64bit code, but want your app also to run on OS versions that only support 32bit.
In XCode you can define for what architecture to build your project, either 32bit only, 64bit only or a fat bundle. In the project settings you can set what is allowed and in the top bar in XCode you can quickly switch between the allowed architectures (your questions 1 and 4).
The base SDK determines what you want to use to compile your application. If you select for instance 10.7 you cannot use new APIs that were introduced in 10.8 or 10.9 (which might perfectly be ok if you want your application to run on earlier OS versions only). However if you want to dynamically use new features if they are availble you'd select the latest OS as base SDK and check in code what OS you are running on and only use new features if they are available. It is totally ok to compile an application with access to new features and run it on older systems if you don't use the new APIs there (they are late-bound and hence only crash when you access them the first time and they are not available).
The deployment target determines the minimum OS version your application needs to run properly. This is a runtime check done when the application is started. The OS will refuse to start an application that is made for a later version.
Say I have a desktop program that uses the Win32 API, but is compiled for the ARM architecture. How do I get it to run on Windows RT (the restricted version of Windows 8 for ARM tablets)? Windows RT refuses to run such apps without a Microsoft signature.
I know there is no official way to do it, but say it is for an in-house deployment, or just for testing purposes. What are my options?
(See this answer for the availability of Win32 API on Windows RT (not neccessarily for Metro apps, but present on the system), and this answer for how to compile Win32 programs for ARM using VS2012.)
Now you can run any app/exe on Windows RT : http://surfsec.wordpress.com/2013/01/06/circumventing-windows-rts-code-integrity-mechanism/
please see this thread,and you can run you exe without a Microsoft signature by CreateProcessA
http://forum.xda-developers.com/showthread.php?t=1944675
And now there is actually a "jailbreak"-like script:
http://forum.xda-developers.com/showthread.php?t=2092158
Usage:
Boot your RT device and log in, allow it to sit on the desktop for about a minute.
Run runExploit.bat, wait for it to do it's thing (shouldn't be more than 20 seconds or so)
Press Volume Down
Wait for runExploit.bat to finish, answer any prompts it gives. They should all be fairly self-explanatory.
It might crash while running the script, and it has to be done after every reboot. Also, I haven't tried it myself. In the post there is a link to a list of recompiled software that might be useful.
I think this is a common problem for all developers using Windows CE 6.0 operating systems on specific hardware. I have a client that needs a custom operating system for its ICOP PDX-089T PC with Touch panel, that is based on DM&P SoC CPU Vortex86DX-1GHz.
I do not have the hardware with me, so every time I make a change I have to send at least the NK.bin file, or the whole ghost image to the client to make the tests for.
Is there any way to build a custom Windows CE emulator to add it to Visual Studio 2005 for testing or may be a custom virtual machine to launch it through VMWare or Virtual PC?
I tried some guidelines from the internet to build one, but every effort in making one resulted in hanging up my PC.
Does anybody have similar needs and some solution?
Note: The emulator I need is for Vortex86DX processor and ICOP board.
Microsoft abandoned the x86 Emulator some time ago, choosing to support only an ARM emulator (the BSP ships in the box with Platform Builder 6.0). This means that you can't create an emulator for the x86 processor, though I'm hard-pressed to think of a scenario where you'd really need to and where just getting hardware isn't a better solution for anyway.
There is a BSP for doing Virtual PC OS builds that would run on x86. It's not had much activity in some time, and I've never tried it, so YMMV.