Anyone using Linux?

[NSFW]

There's a new release of Mono for Wine, and it includes some improvements to System.Windows.Forms.

I didn't know Mono included System.Windows.Forms at all...

The two things that worry me most are support for the DataGridView used by the logger (just because it's pretty complex) and the serial port class. But we have a wrapper for the serial port, and it wouldn't take much to rewrite it using /dev/try or whatever. So if the grid control works on mono, then maybe PCM Hammer will work on Linux. (Minus J2534 tools.)

I haven't got a Linux machine to test with, but if anyone wants to try:

https://gitlab.winehq.org/mono/mono/-/r ... ono-6.14.0

[gametech]

I keep one laptop as a dual boot setup with windows and ubuntu, but too much of the commercial software I use is windows only, so the linux is only used for the occasional project.

[cmaje72]

I have a bunch of old laptops at work. If I get a chance I will give it a try.

Update:
Latest Fedora Live USB with Wine installed from the package manager and updated the latest version of mono. It runs. I'll take it home with me and see if i can brick some ECU's.

[NSFW]

That's pretty cool! The fact that it didn't crash when it tried to list the serial ports gives me some hope. Thanks for giving it a try.

[cmaje72]

I was unable to get it to detect any com ports. Keep in mind though I have never attempted to use Wine for anything and this is probably the first time I have used linux with a GUI in 15 years. I suspect its something with the Wine setup but I have not had the time to experiment yet.

[antus]

I don't want to rain on the parade, but wine has been really good for quite a long time now. I don't understand this whole mono vs dotnet subject, it seems like two implementations of the same thing. dotnet is the main one and mono is maintained by one guy on the wine team. I have a feeling PCMHammer probably was working to this level already. The serial challenge is probably the only thing, as I don't know how the translation layer would work between naming devices and windows style com ports, if at all.

I do know wine is heavily used by games, including by steam to run most windows games on Linux, and performance is good. This includes steamOS and steamdeck also on that OS. Interestingly enough I also found out that the AMD drivers on Linux implement raytracing in software and so that latest indiana jones games which is one of if not the first to require raytracing in hardware wont run on older gen GPUs, but with AMD on Linux it will with the drivers doing the extra work, and graphics quality is still 100% with decent performance. Interesting video on that topic with in game video here: https://www.youtube.com/watch?v=VEo7066YoVo

[NSFW]

PCM Hammer uses a somewhat obscure Windows Management API to get the names of the device drivers for the serial ports.

Replacing that with string[] portNames = System.IO.Ports.SerialPort.GetPortNames() might work, but ideally we'd use the existing code when running on real Windows and use GetPortNames() only on Linux.

Is there an environment variable that we can count on to tell us when we're running under WINE?

I ran into basically the same problem with the Uno Platform UI. Currently it's just using GetPortNames(). That works, but it's a bit easier to know which port is which when you have the driver names to go long with COM1 / COM2 / etc.

[antus]

I asked the question to chatgpt and it gave me this. There is probably a 60% chance its a workable approach.

Code: Select all

using System;
using System.IO;
using System.IO.Ports;
using System.Runtime.InteropServices;

class Program
{
    static void Main()
    {
        string portName = GetSerialPortName();
        using (SerialPort serialPort = new SerialPort(portName, 9600))
        {
            try
            {
                serialPort.Open();
                Console.WriteLine($"Connected to {portName}");
                serialPort.WriteLine("Hello Serial!");
                serialPort.Close();
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Error: {ex.Message}");
            }
        }
    }

    static string GetSerialPortName()
    {
        if (IsRunningUnderWine())
        {
            // Check for available Wine-mapped COM ports
            string[] wineComPorts = Directory.GetFiles("/dev/", "ttyS*");

            if (wineComPorts.Length > 0)
            {
                Console.WriteLine("Wine detected. Using first available Linux serial port.");
                return wineComPorts[0]; // Use first available serial port
            }
            else
            {
                Console.WriteLine("No serial ports found under Wine.");
                return "COM1"; // Fallback
            }
        }
        else
        {
            return "COM3"; // Default for Windows
        }
    }

    static bool IsRunningUnderWine()
    {
        return RuntimeInformation.OSDescription.ToLower().Contains("wine");
    }
}

Straight away I see looking for ttyS* is not good, as many USB to serial devices would come up as /dev/ttyUSB0 and similar.

[antus]

I spent some time trying to see if I could make it run under Linux and if a cheap hack to just change the path to the Linux serial device would be enough. First I tried an ubuntu vm that I had laying around, that was a world of pain getting wine to run at all. Well, not wine, but the gecko html engine and more importantly the fonts. pcmhammer would crash out, unable to find the default font. After much of that I decided to try Fedora and see if I could get to the same stage as cmaje72 above. That was a success, just installing wine was enough to have pcmhammer running with the right dependencies pulled in and working. I used the mock port code that is commented out in the pcm hammer source to add /dev/ttyUSB0 and /dev/ttyUSB1 and made sure my user was in the right group. It listed the ports and let me select them but said no communications with device. It could be that its using the wrong serial library, so still the code above remains untested for now and might still be a step in the right direction.

Then I ran the MDI installer and let that run, and passed through the NDIS network chip to the VM and found pcmhammer had seen the MDI drivers and gave me J2534 options of MDI or MDI2. I picked MDI one and tried to connect and it got close but failed to load the dll and crashed out there. The MDI installer had reported a failure installing a dll wrapper, so that could be the problem there. It's way closer than I expected but still probably not an easy fix on the MDI front. I also tried XPro, same problem. It looks like it can't load the J2534 x86 DLLs.

Code: Select all

=================================================================
	Native Crash Reporting
=================================================================
Got a UNKNOWN while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

=================================================================
	Managed Stacktrace:
=================================================================
	  at <unknown> <0xffffffff>
	  at System.Object:wrapper_native_11dac5a0 <0x00012>
	  at J2534DotNet.J2534:Open <0x00061>
	  at PcmHacking.J2534Device:ConnectTool <0x0006b>
	  at PcmHacking.J2534Device:InitializeInternal <0x001ff>
	  at <Initialize>d__17:MoveNext <0x0004b>
	  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1:Start <0x000b7>
	  at PcmHacking.J2534Device:Initialize <0x000d7>
	  at <ResetConnection>d__29:MoveNext <0x0004d>
	  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1:Start <0x000bf>
	  at PcmHacking.Vehicle:ResetConnection <0x000df>
	  at <InitializeCurrentDevice>d__23:MoveNext <0x00287>
	  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1:Start <0x000c3>
	  at PcmHacking.MainFormBase:InitializeCurrentDevice <0x000e3>
	  at <ResetDevice>d__22:MoveNext <0x00363>
	  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1:Start <0x000b7>
	  at PcmHacking.MainFormBase:ResetDevice <0x000d7>
	  at <HandleSelectButtonClick>d__21:MoveNext <0x00333>
	  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1:Start <0x000bf>
	  at PcmHacking.MainFormBase:HandleSelectButtonClick <0x000df>
	  at <selectButton_Click>d__45:MoveNext <0x0004b>
	  at System.Runtime.CompilerServices.AsyncVoidMethodBuilder:Start <0x000bf>
	  at PcmHacking.MainForm:selectButton_Click <0x000f3>
	  at System.Windows.Forms.Control:OnClick <0x0007a>
	  at System.Windows.Forms.Button:OnClick <0x0008f>
	  at System.Windows.Forms.Button:OnMouseUp <0x00186>
	  at System.Windows.Forms.Control:WmMouseUp <0x004a4>
	  at System.Windows.Forms.Control:WndProc <0x0070f>
	  at System.Windows.Forms.ButtonBase:WndProc <0x002e7>
	  at System.Windows.Forms.Button:WndProc <0x000b7>
	  at ControlNativeWindow:OnMessage <0x0002f>
	  at ControlNativeWindow:WndProc <0x00136>
	  at System.Windows.Forms.NativeWindow:Callback <0x00076>
	  at System.Windows.Forms.NativeWindow:Callback <0x00073>
	  at System.Windows.Forms.NativeWindowProc:Callback <0x000db>
	  at System.Windows.Forms.NativeWindowProc:Callback <0x00067>
	  at <unknown> <0xffffffff>
	  at System.Windows.Forms.UnsafeNativeMethods:DispatchMessageW <0x00012>
	  at ComponentManager:System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop <0x007d3>
	  at ThreadContext:RunMessageLoopInner <0x00749>
	  at ThreadContext:RunMessageLoop <0x0005b>
	  at ThreadContext:RunMessageLoop <0x00087>
	  at System.Windows.Forms.Application:Run <0x0005f>
	  at PcmHacking.Program:Main <0x00053>
	  at System.Object:runtime_invoke_void <0x00064>
=================================================================
wine: Unhandled page fault on read access to 00000000 at address 00000000 (thread 0024), starting debugger...

[joukoy]

Using System.IO.Ports.SerialPort.GetPortNames() you get all ports COM1 .... COM33 (?), available or not.
Setup com port(s) using: wine regedit
HKEY_LOCAL_MACHINE\Software\Wine\Ports
Add new string value, for example COM1 and set Data to real port.

Attached modified version of PortDiscovery.cs, it can detect if running under wine and displays only defined com ports.
It works... almost. Test write is ok, but reading not. Debug log as attachment

I think J2534 devices don't work because passthru dll can't find serial port (FTDI?)
This driver may help, I will check:
https://github.com/brentr/wineftd2xx

Edit: wineftd2xx doesn't help.
Active serial port devices are available in folder:
/dev/serial/by-id/
as symlinks to real devices, so if you find a way to resolve link target, you can list ports. But this is not available in .NET 4.X:
https://learn.microsoft.com/en-us/dotne ... ew=net-9.0