KiCad on ReactOS 4.10-dev

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.

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.

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?

Dunno people asked? I don’t use it on XP but I know someone that does. If XP support is yanked it isn’t a huge deal after all… its a nice to have.

Also relevance is subjective, what matters to me isn’t what matters to our run of the mill script kiddie or black hat hacker.

I think you’ve made your point Rene and it’s not that I don’t agree with you, but @cb88 isn’t asking Kicad developers to support ReactOS. If anything I think it would be the other way around, get ReactOS to support KiCad. The OP was only asking if anyone could help diagnose a particular error message.

1 Like

Yep and in the end I expect KiCad will drop XP at some point… in which case ReactOS will be stuck on whatever version last worked untill they implement enough of the next version of windows to get it working again.

Not entirely sure how this tangent started but KiCad does work on XP and ReactOS is supposed to be equivalent to XP though obviously a bit lacking in this instance… I guess I’ll have to find a copy of windbg and run that on ReactOs/KiCad to make any further findings? I wasn’t able to get anything out of the ReactOS event viewer, and there was no error log etc… even when running from the command prompt either.

Does a nightly build (from before the release) behave the same way? (As far as i know nightlies are compiled with debug info so you could debug the problem that way.)


Hmm, good point I was on a nightly build of ReactOS not sure if debug was enabled, but it was the release build of Kicad… will retest when I get a chance and see if I can get a working debugger on there also the included gdb didn’t seem to work on ReactOS that isn’t really surprising I think though.

Edit: reactos was a debug build, reinstalling kicad nightly now
Edit: there isn’t a debug i686 nightly available at the moment it seems I installed both the latest and the oldest avaiable from the nightliest package and both are release builds.