How to make a DLL for MT4 (using Linux)? - linux

I'm using Linux (Ubuntu) 64bit system and need to make a DLL for MetaTrader4.
I did read lots of things I found about it, but it is very chaotic and confusing. There are many DLLs which are not acceptable for MT4. So far it seems that I need: a 32bit DLL made by using C++. There might be other criteria that I don't know. What IDE/compiler (free, if possible) should I use for it on my 64bit Linux system?
I've never made any DLL, so please tell me if there are other important conditions as well that I should know.

The only way to create a dll for Linux is using .net core however this will not work for anything MT4 related.
MT4 in all its variations is hooked into specifics system level api on windows and the only way to run anything dealing with it on Linux is to build it for windows and run whatever you write from inside wine.

Related

Can one compile Windows code on Linux?

I have an Ubuntu server (with a VPN and a samba share), where I store all my project files and so on.
I would like not to have to back up the files I have on my computer to the server, but instead, directly use the files that are on the server.
But, when I want to build a project on Windows, it gets really slow, since I basically have to be transferring that whole bunch of files visual studio creates through the internet, so I can build the project.
The core concept is:
Open files that are on the server and use them (ie. saving one file at a time is fast enough not to make a difference).
Compile the code on Linux (Maybe code a VS extension with sockets that will tell the server to build, and that server-side, when done building, will send a message back, for VS to run and debug the program). Which would be much better since my laptop is nothing compared to the server performance-wise.
Run and debug the program with VS on windows.
I've so far only been able to find this(which is not what I want because it uses g++, and I'd like VC++) and this(which is not what I want because it's compiling for linux and executing it remotely). What I'm looking for is a mixture of both.
Remote compiling, local programming and executing.
Would also be great because supposedly, I could build with whatever VC++ version I wanted with whatever SDK I wanted. So I could basically easily switch between compiling for Windows 7 and 10.
I'd just like to know: Is it possible to achieve that? And if so how?
Using VC++ directly on Linux is not possible.
To let the Linux server do the compiling with VC++ anyway you could either use wine which apparently works with older Versions (see https://appdb.winehq.org/objectManager.php?sClass=application&iId=5766
) but propably is not easy to set up in a CLI envrioment and might cause License Issues with Microsoft, or use Windows Virtual Machines, which tend to have some Performance drawback.
The best Solution would be to use GCC (g++), which works on a wide range of architectures and operating systems and supports cross compiling.

Create a DLL for VBA Class Module or better alternative?

Here's my issue: I wrote a VBA class module that consists of commonly used methods and functions. I am continually refining the module and making changes to it.
The problem is that I include this module in almost all of my VBA projects and I really don't want to keep importing the new module into each project everytime a change is made.
My question(s): Would it make sense to create a DLL that all of my projects would link to? Or is there an alternative solution that would make more sense?
Thanks
If you're going to create a DLL, which I think makes perfect sense, you might want to do so in a language built on the .NET framework, such as VB.NET or C#. This provides the ability to combat the 32bit and 64bit issue by building both 32bit and 64bit versions.
It's worth noting that a 32bit DLL running on Windows 64bit with Office 32bit will function just fine. It's when the user is running Office 64bit that you need to worry.
With regards to deployment, you could spend a little extra time to create an installer (using NSIS for example) to make deployment much simpler. This installer would serve the purpose of registering the DLL on the target machine. You could also make the installer install both 32bit and 64bit versions of the DLL to guarantee the DLL will be compatible, regardless of the users configuration. I like the idea of registering both bit versions to avoid the scenario where a user has a Windows 64bit/Office 32bit environment and decides to upgrade their Office version to 64bit. If you have the 64bit version already installed, the reference to the DLL will resolve correctly.

Deploy a Qt Application Binary on Linux, compatible with LSB

I have developed a small application in Qt Creator on Ubuntu 12.04 which I want should run on any other linux distro (mostly different versions of CentOS and ubuntu), just like any portable application on windows does.
I want to be able to simply share the binary file of the Application, and run the application.
I am able to successfully do this in windows, by just building the project in QT Creator and then putting the required libraries in the Application directory and then transfering them to other windows systems.
I searched all over and found out that I should be trying to build the project using LSB(Linux Standard Base) Compatibility, so that it runs on other linux distros. Is that the right way to do this?
I am very new to Qt and also to Linux (dont know much of Shell Scripting).
Thus, I dont know how I should proceed to make the Application LSB Compliant.
I have refered to, the following links:
Distributing Qt-based binaries on Linux and
Deploying Qt applications on Linux but have not beem able to understand what I am suposed to do.
I also found this question here which states a very similar situation as mine, but because I am a novice, I dont know how I should do this.
Moreover, considering that the first two articles were written 6 years back, shouldn't there be a simpler way to deploy Qt apps on the linux platform now?
I also saw something about static linking, is that the way to go?
Isn't there a way by which all of this can be done through Qt Creator itself?
If there is no hope of creating a portable Qt Application for Linux, then is there a way, say a shell script or something that would combine all the steps required to compile the Qt project on another computer and run it. Say, download Qt-SDK if not present, run qmake and make and then the newly compiled application, if not already there, so that the user can run the program just by running one script.
Your problem here is not the Linux Standard Base, but rather the presence or not of the specific version of Qt you need (or a later one).
Exactly like on a Windows machine, a user may have any of Qt installed, or they may not have it at all. On Windows it is easier to check for the presence of a certain version of Qt than it is on Linux, thus it is easier to write install tools that automate the experience.
To solve your problem there are a few ways:
Inform the user that your program requires a certain version of Qt or higher, and let the user handle the problem
Learn how to create packages for every distribution you want to target and create specific packages
Use a program like 0Install or Elf Statifier to create a package/executable containing all the necessary libraries.
The latter is similar to what many Windows and Mac programs do (they include every library they need within the installer), but it is not the preferred way on Linux, which relies heavily on shared libraries.
Making a binary application compatible with any other Linux distro is practically impossible since you will never know in advance which libraries are available in distro X, or what version of that library is available. Even among a single distro (e.g. Ubuntu), binary application are almost never backward-compatible, since anything built on Ubuntu 12.04 will have dependencies on versions libraries which are installed on that version of Ubuntu, and trying to run that binary on Ubuntu 10.04 will most probably fail simply because it doesn't have a recent enough version of glibc or some other necessary library.
However, the idea can be much more implementable if you limit yourself to a finite list of distros and versions of those distros. You can then know which libraries are available for those distros, and aim for the lowest common denominator. I used to maintain a binary application which had to support several distros (Ubuntu, Fedora, OpenSUSE, SLED, Mandriva), and the way I would do it is install the oldest distro I was targeting on my build machine. That way, the binary application would be linked to the oldest versions of the libraries available on those distros. Unless there's a new major version of such a library (which happens quite rarely, and even then, distros usually distribute the previous major version for a while for compatibility purposes), your compiled binary will then be compatible with all your targeted distros.
Therefore, the quick piece of advice I would give for your situation, use the oldest LTS version of Ubuntu which is still supported (10.04 at the moment) for your development, and you should be pretty safe for most recent popular distros. For the application you already developped on Ubuntu 12.04, you should have no problem simply recompiling the same source on 10.04. Understand that you will never however achieve 100% compatibility with a compiled C++ Qt application.
If Qt is not all that important to you, you could use a higher-level or interpreted language such as Python, Java, Perl or Ruby. With such languages, you can usually count on the language implementation already being installed on the target distro.
Deploy an application in Linux is a nightmare, luckily there are some solutions. Check this projects to build a portable binary with all their dependencies bundled:
http://statifier.sourceforge.net/statifier/main.html
http://www.magicermine.com/index.html
http://www.pgbovine.net/cde.html
Another solution is make a portable 0install package:
http://0install.net/
I recomend this solution. Personally I have been problems with the 3 first packagers.

is it possible to use a visual studio 2010 c++ code on a linux machine?

Newbie here. I made a project in visual studio 2010, and it works perfectly. Now i need to compile and run this code in a machine that runs ubuntu. Is there some export/import method, or how does it work (of course assuming such thing is possible).
What i am thinking is making a makefile in visual studio, then take the code and compile it in ubuntu? does such thing make sense?
Thank you in advance.
In an ideal world, the code is independent of any IDE or build chain, which keeps its own metadata saparate. Windows doesn't play nice with Linux.
On the other hand if you set up your project with CMake or something like that, then you can generate Visual Studio projects for a given code base just as easily as Linux makefiles.
You shouldn't need to change much code itself. Or, at least you should be aware of what is windows-specific. You probably will have to expend some effort in creating your CMakeList.txt or whatever you end up using, but it's pretty easy once you're familiar with it.
If you mean take Visual Studio source code and compile it on Linux: the answer is yes, though there may be anywhere from zero to a lot of work to make the code compile properly and run. It all depends on programming choices. Unfortunately, standard practice with Visual Studio generally is to use the most Microsoft-specific API features, thus greatly complicating porting to a POSIX or Linux environment. It is possible to make most non-GUI choices very portable, however a GUI intensive program is the least portable unless a cross-platform GUI API is used.
If you mean take the resulting .exe file output from Visual Studio and run that on Linux, that is usually much easier. Install the Wine package, (yum install wine or whatever the Ubuntu equivalent is) and fire up the program with wine program.exe. I have had very good luck (98+%) running Windows programs this way. The major exceptions are Microsoft software: in particular Visual Studio uses many non-standard Windows API operations, so much so that the Wine developers call VS's support level "garbage", a surprising outlier considering the number of Windows games which are well behaved and run under Wine straight out of the box.

How can I compile my Windows program into a single Linux binary that runs with Wine?

Just today i checked my ubuntu with installing wine in it ,
Delphi 3 to 7 worked perfectly (Rad studios did not work because they use .net scraps).
But all of the application i made worked perfectly!!!!!
And i heard that it also works well in mac with WineBottler
Is it possible to create a header linux executable and put my vcl application and requird wine stuff into it and distribute as a single executable (.bin)
there is(was) a solution for Linux from Borland, called Kylix. Kylix is based on some older Qt-stuff.
But I would give FreePascal/Lazarus a try, it's pretty cool! and the compiler compiles for many different platforms.
I guess this is what winelib is for. However I have never tried it. (Wasn't Kylix Delphi + winelib compiled for Linux?)
Since Wine is now stable (reached the 1.0 version some time ago), it could make sense to ask the user to install it using its Linux packages manager. It's very fast and easy. So Wine will be always up to date, according to the distribution used.
Then it's very easy to install any Windows program with Wine.
Since Delphi executables are mostly self-contained (if you don't use the BDE or some external database libraries), your clients will install your Delphi application alla "Windows" way, that is, by running a Setup program from Wine.
And it will work fine, as is.
Using WineLib is not a good idea, even not advised by Wine developers, as far as I remember. At least for closed-source software: in one or two years, perhaps you won't release another version of your program, but Wine and WineLib will have evolved a lot... If you use Wine as an external package, your client can be sure there will be some end user enhancements.
If your software is purely Open Source, then using WineLib could make sense. But even the WineLib headers can evolved, so perhaps your source won't evolve at the same speed...

Resources