Added Support for 32 Bit Apllication

[Zvendson]

Well as the title says: I added support to run the Application on 32 Bit Systems. Its only tested on Windows 11 but I doubt this will cause a problem on Windows 10.

Why 32 Bit? Because my project currently supports 32 and 64 bit. I wanted to change to ImGui long time ago and finally got time for it and Walnut was the perfect opportunity. I hope this might help some people.

Adittionally it extends the .gitignore to exclude build files and the imgui.ini

[Acromatic]

Well as the title says: I added support to run the Application on 32 Bit Systems. Its only tested on Windows 11 but I doubt this will cause a problem on Windows 10.

Why 32 Bit? Because my project currently supports 32 and 64 bit. I wanted to change to ImGui long time ago and finally got time for it and Walnut was the perfect opportunity. I hope this might help some people.

Adittionally it extends the .gitignore to exclude build files and the imgui.ini

Reason why you're the only one supporting 32 and 64 bit.. 64 is just better, it's the new standard and who the hell is running a 32bit linux machine? if it's windows WIN32 is the same thing as WIN64 and operating systems that only support 64, so it doesn't make sense to create WIN64 bindings (which is not easy to do) because you can use WIN32 the same way. Anyone coding games on a linux machine in 32 bit is just insane considering 98% of gaming is steam and epic on windows and consoles which are all 64bit standard now. Coding 32bit software doesn't make sense because either because again you don't need to when all new computers are 64bit... it makes absolutely no sense in 2023 to code for WIN64 or 32bit anything.

[Zvendson]

I smell a little Grudge in you. I appreciate the time you took but u simply forget that there are still legacy programs and libs in 32 bit. I would love to use 64 bit everywhere but i cant, simple as that..

[Acromatic]

uhh... I added support to run the Application on 32 Bit Systems. Its only tested on Windows 11... windows 11 is 64 bit, obviously you didn't read anything I wrote. I seriously doubt your code at this point but I don't honestly care about this, was just trying to inform.

I think I see what your code does, it's adding 32bit support because of your laptops integrated gpu doesn't support 64bit but does support windows 11, which is strange but I've heard of it. Does this sound like your scenario?

If that's the case this should be coded and annotated differently, but it is a hacky start some people could use I'm sure. If that is indeed the case.

As far as any grudge it's nothing towards you or walnut or the cherno.. just that I came back to coding C++ after years of no activity to find a completely new environment in which win32 now means win64 on a modern OS. So I was cheesed pretty badly after spending idk hours, perhaps a day trying to understand an answer to a question I would never thought to have asked in the first place, but I eventually sorted it out. But yes, some warning would be nice considering macros where the former way of handling that and suddenly 4 became 2.

to summarize there are no win64 macros in modern C++, only win32, and only in this case do you need to create bindings for win32, it would be devastating code in most environments, this code needs to be properly identified and is a niche case and at best belongs in an extension folder... but also that project should be a different project as not to bloat this library. You could easily do that yourself.

[Acromatic]

I just took another look at your code, it doesn't even change anything accept add the project macros in vs through the lua premake... you've done this correctly because it changes nothing unless I select the build... but I still don't think it belongs in the main code base because you really should be upgrading your equipment by now, the transition to 64 has given you nearly 20 years lol writing code for 32bit doesn't offer much hope of future support, in fact will literally lose support sometime in the near future entirely.

My opinion might also be heavily swayed by the fact that I'm currently writing a game engine that supports the current standards and has no intention of backwards compatibility in the current transitionary climate.

[Zvendson]

Yeah I completely understand, the sad part is its a third party lib where i dont have access to and will never have. I cant remove the lib as well where i find myself in a bad spot. Im okay not havin 64 bit for this project. Maybe there will be one day that lib gets to 64 bit but the hopes are low.

I just would just love upgrading to a fully customizable window environment like Walnut, its still my baby im working on 😜 I might just write a 64 bit port with IPC but not sure if i really want to. There are only a few variable types that do not exist in 32 bit iirc and writing Walnut to change that would be really cool. Dont think there need to be changed much

[Acromatic]

"I might just write a 64 bit port with IPC but not sure if i really want to."

Windows IPC... I asked my Alexa about it. yeah that is how you use 32bit DLL in 64bit binary. That is how you should be coding if you're already on win11, otherwise it is compiling it in cross incompatible 32/64 anyways... according to Alexa IPC is the only proper way, at least for Windows 64bit Binaries... I highly recommend you do.. or better yet, go find a free one and just use it.

The only issue I'm still having at this point is that I'm not sure your 32bit code works well on my 64bit system.. but maybe I'm wrong and we'll just leave it at that.

Internet { You cannot load dynamically or statically a 32-bit library from a 64-bit application or vice versa.

There are a number of work-arounds that I am aware of:

Make a 64-bit version of the DLL Make a 32-bit version of the application Introduce a COM proxy object (also called a surrogate) as a communication intermediary. Described here. Host the DLL in a separate (32-bit) EXE and use an IPC technique There are a number of inter-process communication (IPC) techniques. Here are a few examples:

named pipe windows messsages socket HTTP listener WCF service (described here) .NET remoting }

YOU KNOW IT'S FUNNY... we're both right... the best way to handle this is by compiling in the correct bit size... however if you start using any WIN64 macros you have made a mistake and need to backtrack it.