Windows support request

[yscontrol]

Is there a way to port this code to run on Windows 10 to support SocketCAN driver with a Virtual CAN (like SavvyCAN, etc)?

[olerem]

No. No one who is using SocketCAN will take a time travel in to begging of 2000 to experience this pain again.

[hartkopp]

Haha, yes. Indeed we had a prototype for SocketCAN on Windows NT somewhere in 2004/2005 based on the NDIS driver model for a PEAK USB driver and some network layer stuff for CAN_RAW and CAN_BCM (that was the intention why the code is GPLv2/BSD dual licensed).
But in that time all the CAN drivers on Windows were closed source - and AFAIK they still are. Making Open Source and open concepts/standards inside Windows OS turned out to be a dead end. Finally CAN hardware vendors would need to give up their HW/SW Lock-In on Windows ...

[Lukasz-Juranek]

I'm interested too in this topic, there was some other issue than lack of open drivers for CAN ?

How much effort do You see rewriting RAW MODE on Windows ?

From some time I'm working on some CANFD converter. Embedded part is finished but I'm struggling to find any general solution for windows support, I would like to avoid writing yet another CAN frames visualization software.

[hartkopp]

I'm interested too in this topic, there was some other issue than lack of open drivers for CAN ?

Yes that was the main issue. When you write a network layer for CAN (like the protocol family PF_CAN in Linux) this implementation needs a common network device interface for CAN interfaces. And this is not provided by Windows CAN hardware vendors - and likely never will be provided. IMO there is no business case for 'professional Windows software vendors" to provide a network device interface which makes your Lock-In CAN hardware exchangeable with other CAN hardware.
For Linux the SoCs with integrated CAN IP cores was a big driver to support the CAN common network interface API. And thankfully some CAN HW vendors that mainly sell CAN hardware (and no Lock-In software) support Linux as well.

How much effort do You see rewriting RAW MODE on Windows ?

IIRC the CAN network layer stuff was no big effort inside the NDIS framework, when you base your implementation on the Linux CAN stuff. But due to the point above it is pretty pointless.

The https://github.com/hardbyte/python-can project has spent much effort in adapting to multiple Windows CAN interfaces. I have no idea if this can be used as a base to send the CAN frames to a virtual CAN network interface which can then be processed by a Windows PF_CAN implementation ??!?

From some time I'm working on some CANFD converter. Embedded part is finished but I'm struggling to find any general solution for windows support, I would like to avoid writing yet another CAN frames visualization software.

¯\(ツ)/¯

[faisal-shah]

I ended up writing a simple CAN bridge using python-can and socketcand . Although the bridge (pycangw.py) is generic in nature, my specific use case was bridging a SocketCAN device in WSL (for example a virtual device) with a CAN device in windows (one that is supported by python-can).

https://github.com/faisal-shah/python-can-gateway

Hope this helps.

[hartkopp]

Great idea! python-can really turns out to be the enabler for CAN applications on Windows. And these applications can then be used on Linux too.

Thanks for the feedback!

Excellent documentation too.

Btw. there's a typo at the end (Testing) : candump -vcan0 -> candump vcan0

[faisal-shah]

Btw. there's a typo at the end (Testing) : candump -vcan0 -> candump vcan0

 Thanks! Will fix it.