Automator-generated apps - Backwards compatibility - backwards-compatibility

In my experience apps created with automator on Mountain Lion don't work on a Snow Leopard machine. The opposite isn't true though: apps created with automator on Snow Leopard do work on a Mountain Lion machine.
I'm creating a very simple wrapper around a command line executable and using cocoa seems overkill. I want the app to work on as many versions of OSX as possible though, so backwards compatibility is a concern.
Any thoughts on that matter? How can I ensure that my Mountain Lion Automator app is backwards-compatible?

Related

Using AppLocale with LabVIEW

I am running LabVIEW 2013 Dev Environment on a Chinese Windows 8 platform. LabVIEW is not a Unicode-base program, and consequently on Asian Windows there are display issues for our interfaces created with US-English character sets. I can fix this problem by setting the language settings for non-unicode programs to English. This works fine, except that all my other non-unicode-based programs are totally illegible.
A quick google search turned up Microsoft's utility for running application with a user-specified code page, AppLocale. The utility is only written to be compatible up to Windows XP. There are two suggested methods I ran accross for installing it: 1. run installer using compatibility settings 2. install using command prompt with admin privileges (apparently it doesn't play well with UAC. You can find one set of instructions here for installing AppLocale on Windows with UAC.
Unfortunately, nothing I have tried has been able to get LabVIEW to use the code page I would like it to. When I run LabVIEW through AppLocale and open the user-interface I am concerned about, the characters still do not display properly.
Any ideas what I might be doing wrong? Could there be a fundamental incompatibility with LabVIEW?
Does anyone know of an alternative to AppLocale that might work for me?
One alternative to Applocale on windows 8 is Locale Emulator created by xupefei. You will have to have visual studio to build the project.
Make sure that your region settings are set to an english speaking region such as the united states of america. You can check this under
control panel >> clock, language, and region >> region settings
Additionally ensure that you have the language packs installed for the character sets used by LabVIEW. You can check which language packs you have installed under control panel >> clock, language, and region >> language
You will want to have installed support for complex languages
If none of these things work I would try upgrading to windows 10 as it has much better language support

Porting a Windows-CE application to Windows Desktop

I have taken over a Windows-CE 6.0 application that I would like to port to other platforms. It is a relatively straightforward, self-contained GUI application, written in Embedded C++ Version 4.0
The very first target I am interested in would be a regular Windows desktop (i.e. XP, Vista, Windows-7).
I understand that porting a desktop application to CE is nontrivial; but what about the reverse, which is what I am interested in? Is going from Windows-CE to Windows Desktop (somewhat) upward-compatible? I sure would love to hear "buy this $1000 Microsoft XYZ C++ development environment and just compile and go!"
(FYI I have no experience with GUI applications nor with programming in the Windows environment; pretend I am but a simple linux/unix guy with decades of C/C++ experience but absolutely no Windows-Fu... ;-)
Porting up should, actually, be pretty straightforward. CE is mostly a subset of Win32, with heavy emphasis on Unicode.
You can probably make sure UNICODE is defined, build and, with a little luck, most of it will "just work". Places that are going to be hangups are:
The UI is likely to be set for a resolution that doesn't match your PC - often CE apps are targeted to a specific device and resolution and this doesn't necessarily come out very aesthetic on a PC.
Anything dynamically loaded (GetProcAddress) from coredll will have to be re-mapped to kernel32/user32/etc
If the device uses the SIP (software input panel - i.e. on-screen keyboard) then all of that has to get stripped out.
If the app uses any Notifications (icons, etc) that has to get replaced
If the app uses any power management, that has to get ripped out
If the app uses any device-specific stuff - especially direct calls to drivers, all of that has to be replaced
If the app is using point to point queues, that has to get replaced
If the app is using the device manager (e.g. to get notifications of copnnected devices) that has to get replaced
Any calls into aygshell.dll are likely to be problematic as well.

Iphone simulator for web development in linux or window

any suggestion for iphone simulator in linux or window? that have browsing ability to localhost or local network?
You can install Mac OS X in VirtualBox and then get an Apple developer account and XCode. Then you can use the iPhone / iPad simulator included. There are lots of tutorials for installing Mac OS X in VirtualBox, but it still takes about 3-4 hours before you have everything setup.
You can also use Safari on a PC. They use the same rendering engine (webkit) and act pretty much the same (minus touch related issues).
You can try this
http://testiphone.com/
not a good one but the browser does it all.No need of simulators;-)

How a Windows Developer can most easily get his software to work well under Wine

Many of my users have been telling me that they'd like to run my software on their Linux machines under Wine.
But I'm a Windows Developer who has practically no experience with Linux.
Now I could spend a month or two installing Linux, learning Linux, installing Wine, learning Wine, and thoroughly ensure my application runs well under Wine. But I am still developing for Windows, so I don't want to take so much time away from development right now.
So what can I do without too much effort to get my program running as well as possible under Wine?
I did find this General help on running applications under Wine.
Download VMWare and an Ubuntu virtual machine (Ubuntu is a popular Linux distribution) from the VMWare site. This will provide you with a working Linux O/S inside your Windows environment without needing to install Linux manually.
You can then use the instructions here to install Wine, that Wiki page also provides you with some instructions on how to use it.
If you follow what Adam Rosenfield suggested and just try running your application in Wine unmodified, you will be able to determine quickly whether there are problems. My guess would be that there are some, otherwise your users would not have contacted you about it :)
There are many ways for getting help with debugging applications in Wine, consult the website for options and pick a few ways that suit you. As always, it's best not to rely on a single channel for communication.
Also, if you are more comfortable with developing in Windows, the approach of using a virtual machine will allow you to compile your code as usual in Windows and copy the binary into the virtual machine for testing (Ubuntu supports browsing/mounting Windows shares).
As long as you're not doing anything unusual such as playing around with hardware or poking around in undocumented API calls and data structures, you should be able to run your code under Wine with few or no modifications. Wine has a fairly complete implementation of the public Windows APIs, so if your program plays nice and doesn't mess around, it should just work.
Don't use too much of the windows API! Don't use anything new from Microsoft ;)
Avoid using WPF is the #1 suggestion.
But it really wouldn't kill you to test your app under Wine. It's not that hard to try; it certainly won't take months. For instance:
Use http://www.ubuntu.com/getubuntu/downloadmirrors#wubi to install
Ubuntu into a file on your Windows machine, then start ubuntu and install the latest Wine from
http://winehq.org/download/deb
Then try running your app's installer.
If it doesn't work, check the Wine FAQ, ask for help in one of the wine forums, and/or file bugs in wine's bug tracker.
Should take about three hours from a dead start to trying out your installer.
I was rather surprised when one of my Delphi5 applications just worked out of the zip.
The only real way this is going to work is to do it yourself, i.e. install vmware and a linux distro as Sean suggested. Linux isn't actually that hard, and we're all here to help.
Having done a quick test I can confirm that it largely works. There is an ACCVIO reading 0x34 during start up, the error dialog can be ignored and the application runs, I opened the Steve McCarthy GEDCOM.
Screenshot
This was using Wine 1.1.12 under MEPIS 7.9.94-rc1_32 under VMWare. Highly recommend to use VMWare for this sort of thing.
What language/platform do you develop with? Depending on which it is, it should be no trouble to get it running native. For example, if you use Java or Python, both operate very cleanly on Linux. Likewise, if you're a .NET developer, you should be able, with some pain, to get your app running in Mono.
Find Linux beta testers. It can reports a bug to WINE developers or find a bug in your application.
Wine is more sensitive to errors than Windows. For example, Wine will crash on NULL window handles, and fail to create windows if the class is invalid, whereas Windows is more robust and will just circumvent the error.
It's an opportunity to clean up your code.
I was amazed at how well Wine ran my app the first time I tried. However, I had to get rid of a third-party driver-based component.

Is there a KDE systray epplet for Enlightment?

Enlightenment DR16 is packaged with openSUSE 11.1 but it's a bit painful to use with KDE apps as there's no obvious (on the Enlightenment site, google etc.) way to provide a systray for KDE apps that require one (e.g., ktorrent).
Anyone know of a way around this?
I'm not using e for the eye-candy - I'm running on a 2.6GHz Celeron and KDE (4.1) performance isn't exactly stellar so I'm trying out a few alternatives.
trayer is a standalone system tray. It should work regardless of what environment you're in, including e16.
Use Docker
I don't know if it works with e16 but it works with Openbox which
is a good window manager for low end machines
Have you tried openbox in your "few alternatives"?

Resources