What Is The Linux Equivalent of Kernel32.Dll

What is the Linux Equivalent of Kernel32.dll?

'kernel32.dll' would also translate to libc.so.6. Since Windows is not POSIX on its lowest level, it needs an additional layer to translate POSIX libc calls into native Win32 calls. This is what msvcrt.dll is for. Kernel32.dll contains the lowest level calls. On Linux, those system calls are already POSIX, so no extra library needed.

what is the equivalent of kernel32.dll in ubuntu?

What is the equivalent of kernel32.dll in Ubuntu?

Kernel32.dll is a Windows-specific library. You won't find it on other operating systems such as Ubuntu (unless you use some emulation layer such as Wine). Thus, you cannot use your platform-specific code on Ubuntu.

So, how do I use named pipes in a platform-independent way?

Luckily, the .NET Framework designers solved that problem for you: .NET Core 2.0 includes the System.IO.Pipes Namespace, which contains managed wrappers for interprocess communication through named pipes.

Is there a Linux equivalent module and function for LoadLibrary() from kernel32.dll that i can call from .Net Core?

A couple of thoughts.

First, yes, DllImport (P/Invoke) works on Linux (and macOS) too.

This seems a bit strange:

    [UnmanagedFunctionPointer(CallingConvention.Cdecl)]
    private delegate short AdcOpen([MarshalAs(UnmanagedType.LPStr)] string adcName, [MarshalAs(UnmanagedType.LPStr)] string protocol, [MarshalAs(UnmanagedType.LPStr)] string port, ref short handle, byte performSwReset);
    private AdcOpen adcOpen;

With the mapping code (LoadLibrary, GetProcAddress, FreeLibrary), this seems like you are manually doing the work that .NET itself does if you do something like this - where you let .NET do the function finding and binding:

    [DllImport("ourdevice.dll", CallingConvention = CallingConvention.Cdecl)]
    private static extern short AdcOpen([MarshalAs(UnmanagedType.LPStr)] string adcName, [MarshalAs(UnmanagedType.LPStr)] string protocol, [MarshalAs(UnmanagedType.LPStr)] string port, ref short handle, byte performSwReset);

Any reason for doing it so differently?

Because if you were to do it that way, I expect the Linux version will look like this and work pretty much the same way as it does on Windows:

    [DllImport("libourdevice.so", CallingConvention = CallingConvention.Cdecl)]
    private static extern short AdcOpen([MarshalAs(UnmanagedType.LPStr)] string adcName, [MarshalAs(UnmanagedType.LPStr)] string protocol, [MarshalAs(UnmanagedType.LPStr)] string port, ref short handle, byte performSwReset);

Assuming you are using the same calling convention and argument marshalling.
The only difference is the name change from "ourdevice.dll" to "libdevice.so". You will also need to place libdevice.so somewhere where it can be found; next to the application executable should work.

If you still want to do it manually via the LoadLibrary/GetProcAddress/FreeLibrary approach, you can use the roughly-equivalent methods on Linux:

• dlopen (similar to LoadLibrary)
• dlsym (similar to GetProcAddress)
• dlclose (similar to FreeLibrary)

See https://stackoverflow.com/a/13492645/3561275 for examples and sample code on how to use these methods.

Windows kernel32 functions in Mono on Linux

You'll need to rewrite the functionality of those functions in native .NET to use them on Mono/Linux (unless you can convince Mono and Wine to play nicely).

If the INI files are controlled, then you may get away with simple file/string manipulation, but then you may be better off moving to something a bit more cross platform anyway.

---

Related Topics