running .net(mono) application in both linux and windows - mono

I have created a c# application in ubuntu using monodevelop. It is running well in ubuntu.
I tried to run that application(firstgtk.exe file created after running in ubuntu)in windows.But it showing error message.How can i make to portable in both linux and windows?
The error message is:
when i click the firstgtk.exe file, a command prompt has come.It is blank. At the same moment microsoft message(send Error report or don't send):
firstgtk has encountered a problem and needs to close.
When i click don't send button, command prompt and message box are gone.

Mono compiles down to CIL code and is completely portable to .NET or Mono on other platforms. I can compile my C# code on a Mac and run the resulting EXE on Linux or Windows under either .NET or Mono.
Without the actual error message we can only guess the issue here. That said, in my experience, the most common reasons an application written in Mono on Linux/UNIX would create an error on Windows are pathnames with platform specific path separators or case sensitivity issues. The Windows file system is not case sensitive but they are on Linux/UNIX.
Another possibility is that you are using Mono on one platform and trying to run it on .NET on the other. Mono ships with a number of libraries that are not present in .NET on Windows.
Actually, I guess a final possibility is that GTK# is a common way to produce GUI code on Mono. GTK# relies on the GTK+ C library being present which is very common on Linux but unlikely on Windows unless it has been explicitly installed.
We really need to know what the error message was.

If you're using Gtk#, your app is portable between Windows and Linux. My guess is that you don't have Gtk# installed correctly (or at all?) on Windows. You can download from here. As of this time the latest version is 2.12.10.

Your code should be portable between Linux and Windows. Alas, the binaries are not. ...
Edit: As commenters have pointed out, Mono does produce and use PE executables, though other issues may limit portability.

Related

Processing affects current directory of Arduino environment

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.

IFilter is not run by Windows indexing service

OS: Win 8.1, x86
I am trying to develop an IFilter for a proprietary file format. The IPersistStream interface is implemented in the filter (although there is no tool to test this interface...). The DLL goes through all the tests in the IFilter test suite (ifilttst, filtdump, filtreg; ifilttst emitted property/values are correct), it is installed in c:\windows\system32 but it is not properly run by SearchFilterHost.exe used by Windows indexing services. Nothing is indexed.
I used Process Monitor (procmon.exe) to look at when SearchFilterHost is using the IFilter. During re-indexing of the disk or when a file name handled by the IFilter is changed, SearchFilterHost loads the image of the IFilter, but then nothing else happens.
Dependency Walker found DLLs that were missing (some are found in the c:\windows\system32) (IEHIMS.DLL, API-MS-WIN-CORExxx.DLL etc...) but I doubt (I could be wrong) it would make much of a difference because the ifilttst is running fine.
I am at my wit's end. Could someone help?
Thanks

How to use WM2003 binary (dll) on Windows Mobile 6.1 (WM6.1) device ? (PE-loader can't accept old binaries)

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.

Running Clojure Box in Windows 7

Has anyone had a problem running Clojure Box in Windows 7?
I am trying to run a fresh install of Clojure Box on a fresh install of Windows 7 Professional (64 bit). Java version on system is 1.6.0_16.
emacs starts up but produces the following error messages:
Warning (initialization): An error occurred while loading `~/.emacs':
File error: Searching for program, no such file or directory, java
As a newbie at emacs, slime, swank, paredit, Clojure and Clojure Box, I'm not even sure where to start. I can't even find `~/.emacs'
Thanks for any help you can provide.
Is the directory you installed Java to on your PATH?
I also got the same error by not having Java installed at all prior to installing Clojure Box. It'd be nice if the installer checked for Java's presence and PATH-belonging. Once Java was installed, Clojure Box was working correctly.
You may create .emacs file yourself. See this answer.
One gotcha is that there is a emulation of the 32 bit process on the 64 bit version of Windows so you need to add java files to C:\Windows\SysWOW64 even if you have it in C:\Windows\System32 folder.

Is there anyway to compile mac binaries from a windows machine?

Seems like there wouldn't be, but it would help us out if there was. I wish to pull the source down to a windows server and compile it and have it be the same as if I had pulled the source code down to a mac machine and used xcode on it. Any Ideas?
Reasons: Release Engineering and IT are much more familiar and comfortable on windows, so it would be easier on us, and LaunchD sucks.
Your original question had less detail... I think you are creating more problems than you are solving buy not using a Mac. Is it really that hard to learn to compile under Xcode or type make in the console?
Anyway...
Apple uses a modified version of the GCC C/C++/Objective C compiler with a proprietary runtime library... You could develop using a port of this code to Windows. See GNUStep.Org. This is not binary compatible though but it isn't impossible that you could rebuild it to cross compile to something that was Mac OS X compatible.
Another idea would be to develop using c# .NET and then move the binaries across to Mac OS X and run the binaries using Mono....
None of these options are robust enough to allow you to do this blind without a Macintosh to test and get up and running in the first place.
You can compile cross app with Cocotron but only on Mac
Why do you need launchd? cron works just as well on Mac as it does on Linux, just have a cronjob that does (Extremely simplified version ahead):
cd /my/source/dir
git pull # You are using Git, right?
xcodebuild MyCoolProject.xcodeproj
cp -r build/MyApp.app /the/distribution/folder