Our vendor provides DLL, which works on Windows. Is this possible to load custom xxx.dll file and use its functions in Linux using Go?
Like this: https://github.com/golang/go/wiki/WindowsDLLs
The short answer is "no": when you "load" a dynamic-linked library, it's not only actually loaded (as in read from the file) but linked into the address space of your running program — by the special means provided by the OS (on Linux-based systems, at least on x86/amd64 platforms that's an external process; on Windows, it's an in-kernel facility, AFAIK).
In other words, loading a dynamic-linked library involves quite a lot of complexity happening behind your back.
Another complication, is whether the DLL is "self-contained" in the sense it only contains "pure" functions — which only perform computations on their input data to provide their output data, — or they call out to the operating system to perform activities such as I/O on files.
The way operating systems provide ways to do these kinds of activities to the running processes are drastically different between Windows and Linux.
The last complication I can think of is dependency of this library on others.
If the library's code is written in C or C++, it quite likely depends on the C library used by the compiler which compiled the library (on Windows, it's typically that MSVCRxx.DLL thing). (A simple example is calling malloc() or printf() or something like this in a library's code.)
All this means that most of a DLL written on Windows for Windows depends both on Windows and the C or C++ standard library associated with the compiler used to build that library.
That's not to mention that Windows DLL uses PE (Portable Executable) format for its modules while GNU/Linux-based systems natively use the ELF format for its shared object files.
I'm afraid not because the windows DLLs do different kernel calls than Linux shared object, both has this fancy name for system library objects
But if you need to run a windows native app on linux I would recommend give Wine a try, I doubt it works properly, and a second worthy try is dosbox, once I doubt this works too
But there is a little hope if those DLLs are written in .net framework, you could wrap them up on a nice c# code and use mono on linux side, not sure if this enables you to import those DLLs to golang, but I don't think so either
In the and with that amount of tricks to have everything working you will get some performance issues, just saying
Related
On Windows, we can register a callback function through LdrDllNotification, so that when any DLL is about to be unloaded, we can get a chance to collect some useful information about that DLL, including its address, size, etc.
I don’t know enough about UNIX-like platforms (including Linux, macOS, iOS, Android, etc.). How can I do the same on these platforms?
On Linux, libraries are loaded and unloaded by the dynamic loader. The loading is usually done automatically when needed by the loader itself, but can also be done manually using the library function dlopen(). The unloading is done manually through dlclose() or automatically at program exit. This is not universally applicable to every Unix system, but only to POSIX compliant ones.
Unfortunately, since (unlike in Windows) the job of loading and unloading libraries is carried out by the dynamic loader (which is just an userspace library), the kernel does not know what is going on and does not provide any mechanism of detecting loading or unloading of dynamic libraries. Even more unfortunately, the loader itself does not provide any such mechanism either. Indeed, there would probably be little-to-no-use for such functionality, apart from usage metrics or similar stuff.
You normally don't even unload libraries at runtime in Linux, unless we are talking about a very complex piece of software that needs to limit its memory footprint when running. The loader loads the libraries when needed at startup (or when the first needed library function is called) and then they are left like any other piece of memory for the kernel to clean up when the program dies.
To my knowlegte, the "best" you could do on Linux to detect unloading of dynamic libraries is:
Create your own shared library implementing dlclose() and preload it when running executables. This is explained here and here.
Continuously watch /proc/self/maps parsing the list of loaded libraries.
Run the program under a debugger like gdb, which can be scripted/automated using Python.
As per other OSes... Android is Linux based, though it has additional security features and apps are sandboxed, unless you root the device or you use a debug shell you can't just "run" other apps hooking them with a custom dlclose() or even a debugger. I can't say much about iOS, but I suspect that implementing such a functionality is not even remotely an option given the very limited abilities of apps (that are also sandboxed). AFAIK macOS also supports dlopen()/dlclose() for manually loading/unloading libraries, however the linker is not the same as the one commonly used on Linux (linked above) so I can't say much about the automatic loading/unloading behavior.
I have an (xxx.so) shared library file and its based on powerpc linux.
now i want to use it in our project but first we need to convert it to X86 or X64 shared library for pc linux.
anyone can help me about this? Is it possible?
You can't: a binary file resulting from compilation of a C/C++ program is compiled for a specific Instruction Set Architecture. Since the two platforms have different instructions sets, you cannot convert the library of an architecture to the other. You need therefore to recompile the library.
First I would say that if you are trying to use functions from a library on one linux to another then there is a very good chance the library is available (somewhere) for your target machine. The odds are that the source code should be available.
If the library is specific to tat version of Linux then you should not be using it for cross platform work.
That said in principle you can :
Run the powerpc version of linux on an x86 or x64 system using a VM.
Try the the decompile-recompile route already suggested to you.
Write your own equivalent library for the target.
See if anyone has written a binary translation application for this purpose.
But if the library you want to use is simply not available for the system you are targeting, then you quite simply should not be trying to use it. It's practically suicidal programming practice.
The code is written in c/c++，may depend some libs in the compiling host;
and it should run in another host without libs depending problems. Both hosts are linux, may have different versions.
Do you have a good strategy?
Pure static linking on Linux is discouraged, it's only really possible if you use an alternative libc (such as dietlibc) which isn't an option with C++, my favoured approach is to build the application on the oldest version of Linux you have to support as the newer libc builds will have backwards compatibility.
This will only cover libc, other requirements, such as gtk, pangom, etc will have to be compiled directly into your binary.
Link the application statically, so that it depends on as few dynamically loaded libraries as possible. This is the general solution to this problem.
Other solutions include:
Ship the required libraries with the application, and override the system's LD_LIBRARY_PATH variable to make the included versions the preferred ones.
Write code to dynamically load the libraries using dlopen() and friends, and handle differences in library versions manually.
Most platforms have a well-defined ABI that covers C code, but ABIs that cover C++ functionality are not yet common.
A program written in c++ using just libc may not run on another platform.
if binary compatibility is an important issue consider using c.
Take all answers for this question into account (static linking, compiling on the oldest Linux, etc.) and then check your final binary by the Linux App Checker to show compatibility issues with other Linux distributions.
I have an application which I need to port on Linux. I was thinking to use Free Pascal the problem is the application uses Windows API's to perform tasks such as serial port communication etc... Is there a msdn for linux users or a book covering how linux works internaly if there are apis.
I am very confused.
Well, it's sad to say but if your code in very Windows-dependend (not VCL depended!) then probably it'll be faster to write the application from the begining rather then porting it.
But if it's only serial port matter then give a try to multiplatform SynaSer library, find it here: http://synapse.ararat.cz.
hope this help :)
Robert Love has a book on Linux Systems Programming - that will cover this area and Love's books are generally good, so it is worth looking at.
It's not entirely clear from your question, but if your concern is that there are specific calls to hardware controlling functions in your Windows application that make it difficult to port I would suggest that is a misplaced fear. Both Windows and Linux operate on the principle that the application level programmer should be kept away from the hardware and that all that should be handled by the operating system kernel and only be accessible to applications via system calls. As the kernels of different operating systems face similar demands from users/applications, they tend to have system calls that do the same sorts of things. It is necessary to match the system calls to one another but I can see no reason why that should be impossible.
What may be more troublesome is that your Windows application may rely heavily on the Windows executive's windowing code/API. Again finding analogues for your code is not impossible but is likely to be a bit more complex e.g. in Linux this stuff is generally not handled in the kernel at all (unlike Windows).
But then again, your code may be written against a portable toolkit/library like Qt which would make things a lot easier.
Good luck in any case.
If the program contains GUI code you must use linux libraries like GTK/XLIB in order to create windows, forms, buttons, etc...
Windows specific functions (like EnterCriticalSection, WaitForSingleObject or _beginthreadex) must be replaced with equivalent linux api functions (a nice tutorial can be found here:
"www.ibm.com/developerworks/systems/library/es-MigratingWin32toLinux.html") or you can use libraries such as w2lpl or wine
A useful library for this kind of problems i've found at http://www.adontec.com/windows-to-linux-port-library.htm
I've had great experiences just using WINE. (https://www.winehq.org/)
You don't really port your app at all. You just make sure it doesnt violate some of the basc constraints of WINE and just run it as is. WINE (though is says it is not) is an emulator of the windows API's and will just do the translation for you. It's pretty complete in its coverage of the API's.
I am looking at some code that uses a function detour package called DetourXS. My application is targeted for Microsoft Server operating systems. Microsoft Research also has a Detours package and they have an article on how it works. They patch the machine code that is loaded in memory and insert code that makes an unconditional jump into the newly injected code.
If this code works by modifying the machine code at run time, they should be facing security restrictions by the Operating System. This would be a serious security lapse on the OS as I can modify any critical DLL like kernel32 to do anything I want. My understanding is that if a user process attempts to modify the code of a dll already loaded into memory, it should be stopped by the OS. Is there a setting in Widows Server OS to enable/disable this check?
How do they overcome this?
Does anybody have experience on using this kind of detour packages in any application in enterprise production environment?
First important thing is that with detours you modify the instructions of your own process. In your process - you can do whatever you want anyways and you don't even have to detour anything, from OS point of view userspace code (e.g. code in your DLL and code in system's kernel32.dll loaded into your process) is exactly the same from security point of view. The reason is simple - hacking security of OS is not the same as changing some code of your process in userspace. OS secures itself by not giving your process too much power (unless you're running as an administrator). For security purposes it is more interesting how to modify code of another process (to achieve its privileges or interesting data, like passwords), but it is a subject for a different discussion.
Secondly, detouring had been considered as a way to implement hot-patching, i.e. patching critical system services on the fly, without reboot. I don't know whether it is currently used/supported by Microsoft (according to google it is), but it is not by chance that standard prolog has length of 5 bytes (yes, it is ideal for putting your jmp instruction).
Despite its name, kernel32.dll is not actually the kernel; it contains the entry points to Win32 API functions that implement Win32's interface to NT system calls.
Furthermore, Windows (like any modern OS) supports copy-on-write, so if you use detours to patch a shared DLL like kernel32.dll, the OS will first make a private copy for your process and patch that. The NT kernel itself is perfectly safe.