Regarding my earlier question about the Point of Mono on Windows, let's say that I develop an app against the windows mono runtime so that it will also run on Linux, OSX, etc.. and to make it more complicated, I use GTK# so that I don't have to deal with WinForms. Is there then an easy way to bundle the Windows Mono runtimes with my Windows version of the application so that it can all be installed at once? Or, is there no point to this? Once I develop against the Windows Mono runtime, would it still run fine against the MS .NET runtime? (I assume I would still need GTK# installed though).
The short answer is Yes.
The things you should take care about while programming are
Not to use platform API
Don't hardcode directory & file name separators, i.e. don't hardcode file paths, but use appropraite class to obtain path separator then concat the names.
Keep in mind that file names on *nx are case sensitve and on Windows are not. While programming don't refer to the same file as log.txt and Log.txt but keep it all small.
Other then that, if you created GTK# application on *nx system, you will be able to run it on Windows if you installed GTK# assembly, and vice-versa.
I did this myself, and it worked like expected. I had a problem to find specific assembly dll version of GTK# on Windows and that took me few hours.
In general, you probably would just use the .Net runtime on Windows. The installer for GTK# for .Net is available from Mono's download page. Your users would need this installed, and then could run you app using the regular .Net runtime.
Related
I'm trying to revive some old software: it was developed on Windows XP, and I'm trying to get it working on Windows 10.
However, this software is dependent on api-ms-win-core-wow64-l1-1-1.dll, which isn't co-operating: Dependencies states that api-ms-win-core-wow64-l1-1-1.dll is missing imports, while Visual Studio's dumpbin states that it has no dependencies.
I'm aware that Microsoft has migrated its functionality and that nobody should link to the implementations directly, but is there any way to get api-ms-win-core-wow64-l1-1-1.dll functionality for this old software on Windows 10? Alternatively, is there an accessible way to rewrite old .dlls to link to Microsoft's Win32 APIs?
(For those who need the file: I got api-ms-win-core-wow64-l1-1-1.dll by running $ locate api-ms-win-core-wow64-l1-1-1.dll on a linux machine with wine installed on it.)
I'm not sure whether this directly addresses your issue. I'm supporting a Java app which uses JNI with some native Windows libraries. I used Dependencies to check what was missing and it turned out to be api-ms-win-core-wow64-l1-1-1.dll (through WS2_32.dll).
The solution for me was to install the latest VC redistributable from MS.
Getting libraries from Wine is probably not a solution, in case you seek to use them outside the linux environment. (They are wrappers and obviously not using native Windows assemblies)
You can get some success by using extracting them from the ReactOS live CD. However, you should be aware that many of these are umbrella libraries, as explained here:
An umbrella library is a single static-link library that exports a subset of Win32 APIs. For example, an umbrella library named OneCore.lib provides the exports for the subset of Win32 APIs that are common to all Windows 10 devices.
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-umbrella-libraries
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis
I noticed that deployed on windows Qt applications are always including the dlls they needed.
Why did they made it that way?
Why can't they do it like on linux? - You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5).
Wouldn't it be better to make it like Java/.Net, e.g. you install Java/.Net then you run/develop applications using only one instance of libraries(dlls).
I find it kinda "unconservating": I have 7 applications that use Qt5, and all of them have Qt5Core.dll, Qt5GUI.dll, etc. and every of them takes some space. Feels like I have 7 packs of Qt5 libraries... x_x
While on linux these same applications use only "one" Qt library.
I noticed that deployed on windows Qt applications are always including the dlls they needed.
This is called "local deployment".
Why did they made it that way?
I can think of a few reasons.
To avoid DLL Hell.
It is sanctioned by Microsoft. They wrote, "You can use this deployment method to enable installation by users who don't have administrator rights, or for applications that can be run from a network share." (see https://learn.microsoft.com/en-us/cpp/windows/choosing-a-deployment-method?view=vs-2019)
You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5)
Qt is a C++ library. C++ DLLs can differ by more than just a major version number. The DLLs could be built with MinGW, or they could be built with MSVC; They could be 32-bit, or they could be 64-bit. The different variants are incompatible with each other.
Example: if you force a PC to have one global copy of Qt 5.14.1 MSVC 32-bit and put that in your PATH, then:
Other Qt apps on that PC that are built with MinGW cannot run.
Other Qt apps on that PC that are 64-bit cannot run.
Apps that must use Qt 5.13 might be broken. (For example, if a critical bug exists in Qt 5.14)
Why can't they do it like on linux? .... on linux these same applications use only "one" Qt library.
I listed a few disadvantages of this approach above. In addition, the version of Qt in Linux distros are usually a few versions behind so applications in the distro repository cannot make use the latest features, bugfixes, or improvements.
That's part of the reason why systems like AppImage and Snapcraft were invented. Sometimes, Linux users also want an app to contain a copy of its libraries, instead of having a single global copy of the libraries.
I already cross-compiled my program for Windows, I now have an EXE and a directory which must reside alongside that EXE in the same directory.
So I need to create an MSI, that places them in the appropriate place (whatever that is) and handles the uninstall too, in a way that is organic with the operative system.
There are Windows tools that do just that, but I haven't been able to find any for OS X. Is there any?
tl;dr:
I am on OS X
I cross-compiled my program for Windows
using OS X, I need to create an installer for Windows, such as an MSI
I DO NOT need to create an installer for OS X, such as a DMG or whatever. I need to create an installer -->FOR<-- Windows, such as an MSI.
I just "happen" to be trying to use OS X to do it.
Using Wine only counts if that program is known to run fine with Wine.
Using a Virtual Machine doesn't count since it is using Windows, which is what I ruled out in this question.
It seems that msi-packager is your solution.
"Build MSI (Windows Installer) packages on Mac and Linux."
https://www.npmjs.com/package/msi-packager
Would it be acceptable to create an EXE-based installer instead of an MSI?
I use InstallBuilder to build installers on OS/X. InstallBuilder is a cross-platform program. There is a version that runs on OS/X and builds both EXE installers for Windows (though I have not tried that combination), as well as DMG/APPs for OS/X.
The InstallBuilder documentation mentions that it cannot build MSIs, because InstallBuilder provides functionality for which there is no equivalent in MSI.
I suggest installing InstallBuilder on your Mac, selecting "Windows" as your output format, and see what happens.
InstallBuilder is one of the better installer builders that I've worked with. It's powerful and comprehensive. Not cheap though. At $995, it's till cheaper than spinning your wheels with WiX. There is a free trial version.
Although WiX is not available for OSX, there's a port of it using the wine library. You can find it in msitools as wixl which can easily installed through brew.
brew install msitools
It sounds like you're looking for the DMG Installer specification for Mac. It's a similar function as MSI in that it is a single file containing the install components needed for an app.
Keep in mind that Mac OSX apps are very different. They are more similar to Windows directories than EXE's. They contain a sub-folder structure which includes the components of the app. If you right click on a Mac app and select "Show Package Contents" you will see a "Contents" top tier folder with everything underneath the app. Just mentioning that as it greatly impacts the lack of need for an uninstall as you simply highlight an app and click delete to remove it and all of its components. There are exceptions of course, but Mac users appreciate when dev's stick to this format.
For DMG this link may help: Demystifying the DMG
Is it possible to develop cross-platform application on Windows and can also compile for Mac OS X from Windows? I have checked Qt but that requires one to compile from Mac using Xcode.
If this is your priority then one option would be Java as at least a jar file built on one platform can be run on another.
If however you're talking about C or C++...
If you are creating a small command line tool then you might be able to make this work with gcc and a cross compiler, but I think it would be a lot of work.
If however you are wanting to create a GUI application I would urge you to give up now. There are so many issues - you'd have to use Carbon or Cocoa APIs which you can't build for on any other platform, you'd have to link against frameworks which won't exist on your compilation host, you won't be able to easily generate .plist files. Qt won't help as you need to be able to build it, which relies on these same frameworks.
In short, there's no alternative to building on an actual mac.
Furthermore, when it comes to fixing bugs, you will absolutely have to do this on a mac (either physical or virtual).
From what I know , in general you do need a mac to make the executable , even for a simple ansi c program you need gcc for mac.
You can create MacPorts Portfile.(If your application is open source)
A MacPorts port is a set of specifications contained in a Portfile
that defines an application, its characteristics, and any files or
special instructions required to install it. This allows you to use a
single command to tell MacPorts to automatically download, compile,
and install applications and libraries.
Take a look at IMCROSS.
IMCROSS is a simple, scripted method of installing cross-compilers and
cross-compiled libraries on a Linux (or possibly other *nix) system,
so that you can develop programs targeted to run on Microsoft Windows
and Mac OS X at the same time and in the same environment as you
develop Linux versions of those programs.
You can certainly do this using Real Studio. It can create Mac OS X applications on Windows without any trouble.
It cross-compiles for Windows, OS X and Linux. And it does it from any platform. It also can create web apps.
Sounds like you should check it out.
All of the documentation I have seen regarding distribution of Adobe AIR apps suggests that an installer is required to be run in order to get the runtime and the app onto a system.
The environment I am working in requires the AIR runtime, the AIR app and associated DLL's (it will be calling Windows native processes) to be transferred to a clean system and this needs to happen without running an install package. Ideally in the form of just copying the necessary files (DLL's, resources etc..) to where they need to be. Scripts can be used for tasks like adding registry keys and similar requirements. The build needs to be automated in the form of a copy, hence why no installer packages are suitable.
Does anyone know whether this is at all possible with Adobe AIR? Note, the app is Windows-only so cross platform is not a requirement.
Thank you in advance for your help
I'm adding more details in this answer.
In order to use NativeProcess your app must be an EXE compiled by ADT using "extended-desktop." I didn't find much documentation ont his, but a normal air app installs silently like this
C:\AdobeAIRInstaller.exe -silent -eulaAccepted "C:\yourApp.air"
Since the ADT compiled EXE already contains air, you can acutally just do this
C:\yourApp.EXE -silent -eulaAccepted -location "\"C:\WhereToInstall\""
I don't believe you need a redistributable license to do this... but I could be wrong. It's easy to get and free so you might as well.
Where yourAPP.EXE is the extended desktop AIR app compiled by ADT. For compiling an EXE by ADT see: http://help.adobe.com/en_US/air/build/WS789ea67d3e73a8b22388411123785d839c-8000.html
No; this won't be possible. You'll have to install the AIR Runtime on the Windows machine to run an AIR app. And I expect the AIR app won't actually run w/o running the AIR App installer.
You may be able to look into alternate non-AIR options to turn SWFs into EXE. Zinc is one such software to do that.
Or it is possible you can create an invisible installer. I believe if you sign up for redistribution of the AIR Runtime there is a way to make the runtime installer "invisible". I'm not sure about the app, though.