I have compiled and linked my code written in C and C++ and calling certain Windows APIs to a Win32 .dll using MinGW in Code::Blocks runnings on Windows XP. My code has also been compiled to and linked to create a Win32 .exe, which works successfully whilst communicating serially from PC to a motherboard through either physical port COM1 or COM2, as selected by a .ini file.

I have some open source C# code, whose GUI identifies the available physical or virtual COM ports and allows selection of any available COM port for serial port communications. I can use the .ini file to use the selected COM port in the Win32 .dll. I can then call the Win 32 .dll into the rewritten C# code using a p/invoke call and use MonoDevelop on Ubuntu Linux to compile and link my code to create an executable which runs on Linux and Mac OSX.

Would the GUI element allowing the identification and selection of physical or virtual COM ports and the Win32.dll GUI element still work as on Windows?

Thanks

Finston

I have compiled and linked my code written in C and C++ and calling certain Windows APIs to a Win32 .dll using MinGW in Code::Blocks runnings on Windows XP. My code has also been compiled to and linked to create a Win32 .exe, which works successfully whilst communicating serially from PC to a motherboard through either physical port COM1 or COM2, as selected by a .ini file.

I have some open source C# code, whose GUI identifies the available physical or virtual COM ports and allows selection of any available COM port for serial port communications. I can use the .ini file to use the selected COM port in the Win32 .dll. I can then call the Win 32 .dll into the rewritten C# code using a p/invoke call and use MonoDevelop on Ubuntu Linux to compile and link my code to create an executable which runs on Linux and Mac OSX.

This sounds like an incredibly convoluted setup to do something extremely simple. From what I understand, you need a little GUI dialog that will list the available serial ports and allow the user to select one. That's less than a 100 lines of code, and at most a few hours of work to write it, assuming no familiarity at all with the needed APIs. Why go through all this trouble?

Would the GUI element allowing the identification and selection of physical or virtual COM ports and the Win32.dll GUI element still work as on Windows?

I don't know what you mean by "the Win32.dll GUI", but certainly, anything that uses Win32.dll (or any dll for that matter) will not work in Linux or Mac, i.e., this is only for Windows. If you run it under a Windows emulator like Wine, it might sort of work, but don't expect it to look the same or work at all.

As for the .NET GUI and the COM port enumeration, I really have no idea. This all depends on how far the Mono project has come. I believe that porting Windows Forms (the main .NET GUI toolkit in Windows) applications to foreign environments (Linux, Mac, or other) will produce somewhat ugly results (i.e., looking like Windows 95-XP-ish GUIs) that don't mesh well with the rest of the environment. I believe the problem has to do with WinForms being very Windows-oriented with lots of non-portable elements (so much for the "cross-platform-ness" of .NET). .NET code is only portable in theory, despite all efforts, I don't think it will ever be an effective platform-agnostic tool, and I don't think Microsoft is really interested in making that happen anyways, despite what they claim.

Porting code that is so deeply tied to the Windows environment (Win32 API calls, Win32 COM port code, .NET GUI, and .NET COM port code), and especially for such a simple task, seems like a massive waste of time and will be much more painful than you think (unless you're very lucky).

You'd be better off using Qt and QtSerialPort as a real cross-platform solution. Otherwise, just write the code, I means, it's just a couple of hundred lines.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.