I need to run a local application on a windows CE 6.0 platform I am doing some work on.
Basically, ALL I need to do is run a command line application with a few arguments. I don't really even need to see the return value.
Basically, I have a little closed-source CE program which interacts with some specialized hardware, and I'm trying to control said hardware from within the software I am working on. Once I have everything set up, I am interacting with the hardware through it's API, but there are a few configuration settings which the API neglects to expose, and I need to alter to make everything work correctly (I'm working on getting the manufacturer to fix the API, but I need a working prototype soon).
Everything I have read says the system() call is what I need, but it does not seem to be present in Windows CE's stdlib.h.
ShellExecuteEx seems to be available, as does CreateProcess, if ShellExecuteEx isn't sufficient (and it should be), CreateProcess definitely will be, if a bit more work.
Related
I make a game using vb.net & wpf. But I want this run on Windows/Linux/Mac.
How can I do it?
I'm sorry my english is really bad :D I use Google translate.
Implementing a solution for multiple platforms is not an easy task and you need to be familiar with all the platforms you plan to support, starting with trivialities such as different path schemes and ending with checking every reference you require by your project settings for its compatibility to the target platform.
Please have a look at http://www.mono-project.com. When you install the mono package to your system, you can run your compiled .exe as it is from the shell under certain circumstances.
Obviously, you need to decide whether you try to create one application that runs on all target platforms OR if you want to create platform specific applications all referencing to the same game engine.
If you stick very close to the framework not using external references, chances are higher to achieve the former. If the main logic of your game can easily be compartmentalized into a dedicated project, the latter is the way to go.
In general, cross-plattform compatibility is more easily to achieve if your application backend consists of a console application to be accessed by a webbrowser installed on the system - using a web frontend though. But as long as you do not require accelerated graphics, this should be feasible.
We're migrating a legacy system that runs under Citrix from .NET2/32 to .NET4/64. Part of the existing system uses a product called BarTender from Seagull Scientific that is used to print out barcodes.
Due to various constraints we must use BarTender from the application but from a technical perspective, we can't directly call the BarTender 32bit (only) managed code that the bartender controls consist of from our 64bit application. I know that we'll have to go across a process boundary by some method as the two halves will have to run in separate spaces.
Following various suggestions on Stack and the web in general, I've gone down the route of trying to create intermediate COM objects (i.e., create a project in .NET and register for COM interop) in 64bit and 32bit guises to see if I can call those to provide this "step down" from 64 to 32 bit but I either end up going round in circles using tlbimp.exe to create a 64 big runtime callable wrapper or to use regasm.exe to go the other way around.
I'm sure that this has all been done before but I've not found a complete guide that describes the correct steps and appropriate tools to use.
*Create your 64bit application like this.
*Do these steps or create these intermediates by the following process
*Create your 32bit application like this.
*Set it up like this so that it can be called.
We MUST run in 64bit on Citrix, so forcing the application to run in 32bit isn't an option.
I've already looked at this article
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
and the suggestions in this post
Calling 32bit Code from 64bit Process
But I can't quite get things to marry up.
Any suggestions ?
If I have an application that is written in .net Compact Framework (and runs on Windows CE) and is theoretically compatible with Windows Embedded Standard O/S, would it still be compatible if it makes use of OpenNETCF functionality?
Things like running .exe files with help of OpenNETCF for example. I am assuming that OpenNETCF uses P/Invoke under the hood, which might make the application incompatible with other OS than Windows CE.
I don't use P/Invoke in my code, but I can't asnwer for sure whether OpenNETCF does or does not.
.net compact framework 2.0 and windows embedded standard
OpenNETCF does use P/Invoke extensively.
It is effectively a wrapper for some core OS functionality in Windows CE and its derivatives, that is not otherwise implemented in the Compact Framework. In practice this means extensive P/Invoking of coredll.dll; the basic OS module for Windows CE.
Windows Embedded Standard is Windows XP. For this reason I would not expect you to be able to use OpenNETCF.
Depending on the version you're using you may be able to get hold of the OpenNETCF code here (or buy the latest of course), and see what's going on under the hood. Also, what you may find is that the calls you are making to the OpenNETCF are actually implemented anyway when compiling for Windows Embedded Standard.
One way to approach this is to make another project to target this platform, containing exactly the same code files, but no reference to the OpenNETCF, then work through fixing the compile errors.
You can add a Conditional compilation symbol to either the CE project or the Windows Embedded project then fix the errors like so (This example is not for OpenNETCF, but you get the idea):
public static string ExecutingAssembly
{
get
{
#if WindowsCE
return Assembly.GetExecutingAssembly().GetName().CodeBase;
#else
return Assembly.GetExecutingAssembly().Location;
#endif
}
}
Obviously you will then have to create a build for each platform as the outputted assemblies will now be different.
As Chris points out, the SDF makes heavy use of coredll P/Invokes. That's not to say everything does, but it's certainly a minefield. I tend to have a CF project and a FFX project and places where I have overlap I use aliasing, like this:
#if WindowsCE
using Thread = OpenNETCF.Threading.Thread2;
#else
using Thread = System.Threading.Thread;
#endif
Then in the code you just do your normal
var thread = new Thread(...);
And things work out.
Now ages ago we did start an interesting side project of creating a coredll "shim" for the desktop. What that means is that a p/invoke to "coredll" on the desktop would actually call that DLL, which would in turn marshal the calls off to kernel32, user32 or whatever. Our testing for what we implemented (and there's a fair bit there) showed that it worked just fine, so if you're using a limited subset of APIs, just dropping it on the PC might make the CF assembly "just work".
I need to build a fairly simple app but it needs to work on both PC and Mac.
It also needs to be redistributable on a disc or usb drive as a standalone desktop app.
Initially I thought AIR would be perfect for this (it ticks all the API requirements), but the difficulty is making it distributable, as the app would require the AIR runtime to be installed to run.
I came across Shu Player as an option as it seems to be able to package the AIR runtime with the app and do a (silent?) install.
However this seems to break the T&C from Adobe (as outlined here) so I'm not sure about the legality.
Another option could be Zinc but I haven't tested it so I'm not sure how well it'll fit the bill.
What would you recommend or suggest I check out?
Any suggestion much appreciated
EDIT:
There's a few more discussions on mono usage (though no real conclusion):
Here and Here
EDIT2:
Titanium could also fit the bill maybe, will check it out.
Any more comments from anyone?
EDIT3 (one year on): It's actually been almost a year since I posted that question but it seems some people still come across it every now and then, and even contribute an answer, even a year later.
Thought I'd update the question a bit. I did not get around to try the tcl/tk option at the end, time constraint and the uncertainty of the compatibility to different os versions led me to discard that as an option.
I did try Titanium for a bit but though the first impressions were ok, they really are pushing the mobile platform more than anything, and imho, the desktop implementation suffers a bit from that lack of attention. There are also some report of problems with some visual studio runtime on some OSs (can't remember the details now though).. So discarded that too.
I ended up going with XULRunner. The two major appeals were:
Firefox seems to work out of the box on most OS version, so I took it as good faith that a XULRunner app would likely be compatible with most system. Saved me a lot of testing and it turned out that it did run really well on all platforms, there hasn't been a single report of not being able to start the app
It's Javascript baby! Language learning curve was minimal. The main thing to work out is what the additional xpcom interfaces are and how to query them.
On the down side:
I thought troubleshooting errors was a sometimes difficult task, the venkman debugger is kinda clunky, ended up using the console more than anything.
The sqlite interface is a great asset for a desktop app but I often struggled to find relevant error infos when something didn't work - maybe i was doing it wrong.
It took a little while to work out how to package the app as a standalone app for both PC and Mac. The final approach was to have a "shell" mac app and a shell pc app and a couple of "compile" script that would copy the shells and add the custom source code onto it in the correct location.
One last potential issue for some, due to the nature of xulrunner apps, your source code will be deployed with the app, you can use obfuscation if you want but that's something to keep in mind if you want to protect your intellectual property
All in all, great platform for a cross-platform app. I'd highly recommend it.
Tcl/Tk has one of the best packaging solutions out there. You can easily wrap a cross-platform application (implemented in a fully working virtual filesystem) with a platform-specific binary to get a single file executable for just about any modern desktop system. Search google for the terms starkit, starpack and tclkit. Such wrapped binaries are tiny in comparison to many executables these days.
Many deride Tk as being "old" or "immature" but it's one of the oldest, most stable toolkits out there. It uses native widgets when such widgets exist.
One significant drawback of Tcl/Tk, however, is that it lacks any sort of printing support. If your application needs to print you'll have to be a bit creative. There are platform-specific solutions, and the ability to generate postscript documents, and libraries to create pdfs, but it takes a little extra effort.
Java is probably your best bet, although not all Windows PCs will necessarily have Java (most should). JavaFX is new enough you can't count on it - you'll probably find a lot of machines running Java 1.5 or (shudder) 1.4. I believe recent Mac OS still ships with 1.5 (latest version may have changed to 1.6).
Consider JavaFX
It would run everywhere with a modern JRE ..!
AIR could be an option, but only if you don't mind distributing two different files (the offline runtime installer and your app), and expecting the user to run one and then the other. You do have to submit an online form at Adobe's site saying you agree to distribute the offline installer as-is, rather than digging out individual DLLs or whatever, before they give you the installer.
Unfortunately there's currently no way to get both an AIR app and the runtime to install from one file though. I'm not sure what the deal with Shu is, or whether it's doing anything that isn't kosher.
i would recommended zink. it has all the functionalities you require for desktop. however, the las time i used it it was a bit glitchy.
i was hung up by trying to write a 6M file to the disk. thought it trough and changed the code to write 512K chunks at a time (3min work, fast).
probably it still has some little annoying glitches like making you think on root lvl but the ease of use and the features are just way too sweet to ignore.
I'm looking at rewriting an eMbedded Visual Basic app I wrote years ago. I'm unsatisified with it because of various problems clients keep having with it now and then over the years, mostly along the lines of the app not loading anymore because a required dll/activex control has gone missing! This is so frustrating and naturally difficult to debug when a client is using it far away. In alot of cases reinstalling the app doesn't fix the problem.
My preference would be to rewrite it in C# since I'm comfortable with C# and DotNet, but I'm also open to other platforms like blackberry or iTouch/iPhone so long as the platform can support maps and GPS. I'd start rewriting it in C# now but I can't be sure that I won't have the same problems in .net.
Has anyone else had similar problems with eVB apps which have gone away/persisted when moving to CF DotNet? Or would you suggest a different platform again?
Edit: Note that I wish to move away from eVB anyway, but if I move to CF DotNet I want to make sure I won't have the same missing dll/control problems.
I recommend .NET CF strongly, especially if you already know C# and .NET. Mono has been ported to the iPhone, so it is possible to write apps that will run on Windows Mobile and the iPhone. No Mono for Blackberry (yet, if ever), so that's a definite limitation. I personally can't stand Blackberries (I have both a Blackberry and a WM smartphone and the Blackberry makes me want to hang myself), but they do have a huge user base.
You should have migrated away from eVB years ago, but that's water under the bridge. If you want to continue targeting Windows CE/ Windows Mobile I'd recommend going to the CF - language is irrelevant, use what you're comfortable with.
There's no way to guarantee that whatever your "missing DLL" problem is won't happen again, since we have no idea what DLL went missing. If it was a 3rd party control, then you're at the mercy of the market. If the provider survives, it's likely their control will.
If you want to target iPhone/Blackberry then Java is more likely to be your language of choice - the tools I'm not as familiar with. Eclipse for Blackberry - iPhone may have their own tool.
As for Silverlight, you might look at it, but so far it's just way too slow to be a viable platform, at least on any WinMo device I've ever seen. We've delevered many, many CF apps for all sorts of verticals and have never had any usability problems (though we've been doing it a long time and know every limitation and what we should and should not be trying).
I suggest you take it one step further and look at Silverlight. One of the premises is that it's a more long-term-stable, portable, lightweight download and install, and it hasn't gotten krufty yet.
I think it has the potential to be the next VB for embedded. One of the difficulties with CF is that I've found it to be an insufficient subset of the real thing.
Another option is NS Basic/CE. It's highly compatible with eVB, so you will be able to keep most if not all of your code. The product has been continually updated so it runs on current devices.
The installer that NS Basic/CE creates includes all the dll files your program requires, so they will be included on installation.