KiCad on ReactOS 4.10-dev

So, I can install and run KiCad on ReactOS… however if I try to start PcbNew I get an error saying it can’t find _pcbnew.kiface any idea why this might be? The rest of KiCad seems to work normally except PcbNew.

The file actually is there… I imagine this is some sort of ReactOS issue but I have seen it before a long time ago on KiCad on real Windows so figured I’d get some direction to look here first.

Note it is installed in C:/Kicad I also tried at the default path with the same error:

image

It may be a bug in ReactOS!

Better to ask on ReactOS Forums or even Report a bug!

Bricscad 14 works =)

Did you post that to the wrong topic? (I would assume you intended it for the one where somebody asked about single line schematics)

Nope, not wrong.

Just an example of working program in ReactOS.

I don’t think anyone will fancy supporting KiCad on ReactOS until it gets to Beta. Interesting that it even started though

Well the point is if KiCad works on XP and it seems to at least enough to use it (3d view is a bit wonky and the raytracer crashes)… it should work on ReactOS (Server 2003) it isn’t something KiCad has to do additionally…

Like I said before … I’ve seen problems with loading the kiface files on real windows before as well so was hoping for some suggestions as to what the problem might be.

ReactOS forum post.
https://reactos.org/forum/viewtopic.php?f=2&t=17314

KiCad may work on XP but its unsupported really by anyone working on it. Additionally it uses MSYS2 which uses CYGWIN. Both of them have ridiculous levels of hacks wrapping Windows API to create a Unix API. Also Cygwin has officially dropped support for Windows XP and make no guarantees of compatibility and that pulls up into msys2.
In the Kicad 5.0 release, I pushed an upgrade to the msys2 used in the installer because it stopped working properly on Windows 10 1803 yet again due to Microsoft changing the process spawning model again (internally, not an api change) and CYGWIN depends on kernel memory hacks to emulate fork() that go beyond the api.

So theres plenty of things that could be wrong on ReactOS just due to the use of MSYS2/CYGWIN which are already giant piles of duct tape on top of Windows.

For the record, kiface files are just DLLs. Someone back in the day thought instead of using native OS extensions for .dll and .so…they’ll make .kiface, it serves no purpose but yea. However due to how the DLLs are loaded, if theres any loading errors such as missing system DLLs or system exceptions, they tend to get covered up by the generic load message instead of a detailed system message.

I don’t know if ReactOS has emulated the Event Viewer but a more detailed failure reason would normally be sent there by Windows.

1 Like

I’m aware of what a hairball windows/reactos/msys etc… can be and that it’s unsupported. There’s no need to go further on that. Technically ReactOS is targeting XP compatibility by beta / 1.0 etc… but in some cases is adding post XP functionality as people have time.

After having thought about it some this probably comes down to MSYS2 not working on FAT filesystems… which is all ReactOS currently supports. Other filesystems are being worked on so maybe it will just start working.

I was already aware of what the kiface files are as it came up in past discussion.

The event viewer is there but didn’t pick up any error from KiCad (though there were a few others from other applications I installed). Obviously take with a grain of salt there… there were actually 2 errors the one I posted in the first screenshot and then this one.

Yeah it is interesting at least which is why I posted… even at Beta I dunno if it will be supported as at that point it will still be essentially XP, if they add enough Vista/Win7/Win10 compatibility though it would certainly be an interesting option for people that don’t get Linux\BSD etc…

There has been a similar problem on Linux as well

It would be interesting to see this OS ported to an embedded application.

That means that the .kiface was found and loaded, but a procedure was not found in the file. https://stackoverflow.com/questions/25877507/getprocaddress-failing-error-127

Often due to a name mangling problem, probably a build error.

In the case of ReactOS, its usually just an unimplemented Windows API call. Theres some tools for reactos I think to debug/catch whats unimplemented.

1 Like

I did raise a point about dropping XP and 32 bit support for KiCad 6, but nobody commented. I suspect very few are actually installing V5 32 bit these days, so it is already under-tested.
I have several XP machines in my office, running critical abandoned applications for programming radios and maintaining radio networks.

Well, I would imagine a lot of people that would use KiCad on older PCs… ie lab PC in the workshop etc… it isn’t like KiCad is a resource hog anyway so hopefully it runs on older PCs as long as it can reasonably do so. KiCad is free software after all… and the people using it don’t necessarily have loads of cash laying around… and the more cash they spend on their PCs the less they have to donate :wink: so catch22?

Really the only reason I thought to install it on ReactOS was someone I was working on a project with (vogons forum) happens to only have PCs up to the XP era.

And as you allude to… radio operators, enthusiasts, hams, etc… may not have the latest PC gear, or have to stay on old gear but often contribute to the electronics community.

At work there was a lab PC untill recently that I would use to remote into my laptop to check components etc as I was building PCBs when I was too lazy to fetch my laptop, that was win2k… obviously not running KiCad but using remote desktop.

Running a no longer maintained operating system is never a good idea. Not even on outdated hardware. We are in the information age. As soon as you connect something to the internet it has to be maintained. So you would be better of to run a lightweight linux on such a system instead of using a legacy windows system that does no longer receive critical security updates.

I don’t think dropping XP support would be much of an issue, especially if doing so meant being able to make use of features of more modern operating systems.

But I think it is a bit premature to drop support for 32 bit operating systems. Anyone can run the 32 bit version but not everyone can run the 64 bit version.

Blanket statements are bad ideas too… didn’t stop ya. Frankly if I feel like strutting around on the net from Opera 9.52 on my Sparcstation 20 I’ll just go ahead and do so… NO FEAR ahem. It isn’t like older OSs are the main targets of malware these days anyway they are so few and far between that it just isn’t worth attackers bothering with… security through irrelevance.

You could even argue that more modern OSes are inherently less secury by having larger attack surfaces due to the myriad of mostly useless services they provide… active tiles on the start menu, push notifications etc… all gigantic holes in windows 10.

If it is irrelevant why should developer resources be used to create kicad for it?