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.
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.
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.
It would be interesting to know how many KiCad downloads now are 32 bit, but by the time V6 comes out 32 bit OS are going to be rare. No PCs have been 32 bit only for some time.
Some PCs deliberately have 32 bit OS for better 16 bit support for legacy POS etc support
Software advances no hard feelings
As an engineer one thing that has always bothered me is the constant advance of software utilization of the resources provided to it… given a constrained environment software tends to get faster on the same hardware, but unconstrained it gets slower and slower over time potentially even performing worse on faster hardware than it started out on… I think it is in part because it is so difficult to recognize the trade offs one is making as software is developed. If software engineers can’t solve these problems why should we expect people in other fields to solve their own seemingly trivial problems with any less difficulty. Granted KiCad developers seem to be fairly cognizant of such issues and take more care than most.
I mean there isn’t anything particularly that one of my Sparcstation 20’s is incapable of supporting as far as KiCads features go… but of course convenience of programming and the extra effort required to get such things to run on computers that slow trumps that any day. And obviously somethings would be very limited, ie most work would be in wireframe, raytracing would probably best be done over the weekend… and it would probably take a day or two to build KiCad on 8 way SparcServer 1000e (I have 3, I plan on getting 1 working maxed out)… ccache for the win.
It’s been stated before that office productivity hasn’t really increased since the early 90’s, open floor plan offices actually decrease communication between coworkers (dons headphones) and the support infrastructure for niche applications becomes increasingly fragile (where I work a simple accounting software has require days of on site support to upgrade/implement) something that might not seem unfamiliar from the early days of PC computing.
That said I think it’s worthwhile to point out that the average IT guy… from his perspective has bigger things on his plate than moving to 64bit and breaking half his proprietary software install base, when the software in question doesn’t need 64bit… and in fact most office applications could get by with 16bit code with some minor caveats, we should try to always be understanding of the issues others face. Some of the industrial software I use today still has some 16bit limitations in it I have to work around! Such as creating > 64k unique variable names blows it up (you can have > 64k variables they just have to be in arrays). I only saw this as someone decided it was a good idea to ignore array support, and hard code indexes in the variable name (useless in that case buy a useful hack for lack of nested classes shudders).
KiCad will as many other softwares have done eventually move on, and perhaps even drop 32bit support… but that fine and understandable especially as 32bit support crumbles beneath it… but it does leave that nagging thought in the back of my mind that nothing KiCad or 90% of any software out there does really needs 64bit… I personally am not sure that ubiquitous 64bit support is a panacea to the problems we face and in fact brings it’s own challenges.
Obligatory paragraph to stay on topic lol… I attempted to install the Reactos Build envoinment and toolchain… git ended up locking up and acting wierd once I tried to checkout the codebase… suspect FAT32 is too fragile to cope… good thing they ware working on booting from BTRFS I guess.