# Removing 32-bit Windows support and separate Lua states **URL:** \ **Category:** Announcements\ **Created:** [September 7, 2026, 2:20pm UTC](https://forum.defold.com/t/removing-32-bit-windows-support-and-separate-lua-states/83211 "2026-09-07T14:20:41Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![AGulev](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/agulev/32/4541_2.png) [@AGulev](https://forum.defold.com/u/AGulev)\ **Post date:** [September 7, 2026, 2:20pm UTC](https://forum.defold.com/t/removing-32-bit-windows-support-and-separate-lua-states/83211/1 "2026-09-07T14:20:41Z")
In the next major version update, 1.14.0 (will be released after the next 1.13.2 release), we plan to remove support for 32-bit Windows and the option to use separate Lua states for game object, GUI, and render scripts. **32-bit Windows** Maintaining a separate 32-bit Windows target requires additional builds, dependencies, and testing. Removing it will reduce maintenance effort and simplify our build infrastructure. Windows development and bundling will use the 64-bit platform, `x86_64-win32`. Building games and native extensions for `x86-win32` will no longer be supported. If your build scripts target `x86-win32`, update them to use `x86_64-win32` instead. See [PR #13109](https://github.com/defold/defold/pull/13109) for details. **Lua states** Defold currently supports either one shared Lua state or separate states for game object, GUI, and render scripts. A shared state uses less memory and is already required by the editor debugger. Removing the separate-state option will simplify script initialization, updates, and native extension handling. ![CleanShot 2026-09-07 at 16.20.08@2x](https://forum-defold-uploads.b-cdn.net/original/3X/a/c/ac9164e04ef046f02913304e4589653a18653ef3.png) Starting with 1.14.0, all three script types will always share one Lua state, and the **Shared State** project setting (`script.shared_state`) will be removed. Projects that already use a shared state will keep the same behavior. Projects that use separate states will now share global variables and loaded Lua modules between script types. See [PR #13111](https://github.com/defold/defold/pull/13111) for details. * * * If you have a project that still depends on 32-bit Windows, please provide more information about your audience and use case. This will help us understand the impact of removing this platform. If your project uses separate Lua states, you can prepare by enabling **Script → Shared State** in `game.project` and testing your game. Pay particular attention to global variables and mutable state stored in Lua modules. If something on our side blocks this migration, please [create an issue](https://github.com/defold/defold/issues) and provide a repro project so we can investigate it before the release. ---
**Author:** ![britzl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/britzl/32/23_2.png) [@britzl](https://forum.defold.com/u/britzl)\ **Post date:** [September 7, 2026, 4:31pm UTC](https://forum.defold.com/t/removing-32-bit-windows-support-and-separate-lua-states/83211/2 "2026-09-07T16:31:44Z")
---
**Author:** ![ackle](https://forum-defold.b-cdn.net/letter_avatar_proxy/v4/letter/a/13edae/32.png) [@ackle](https://forum.defold.com/u/ackle)\ **Post date:** [September 8, 2026, 12:05am UTC](https://forum.defold.com/t/removing-32-bit-windows-support-and-separate-lua-states/83211/3 "2026-09-08T00:05:24Z")
> Starting with 1.14.0, all three script types will always share one Lua state, and the **Shared State** project setting (`script.shared_state`) will be removed. Projects that already use a shared state will keep the same behavior. … Phew, good thing it’s not the other way around, or I’d have to refactor my whole project. ---
**Author:** ![AGulev](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/agulev/32/4541_2.png) [@AGulev](https://forum.defold.com/u/AGulev)\ **Post date:** [September 9, 2026, 6:39am UTC](https://forum.defold.com/t/removing-32-bit-windows-support-and-separate-lua-states/83211/4 "2026-09-09T06:39:45Z")
~~I’m surprised that someone would use separate states for Lua (I was sure everyone use Shared State). Could you please explain why you chose this approach?~~ Sorry, I misread it. ---
**Author:** ![boruok](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/boruok/32/21851_2.png) [@boruok](https://forum.defold.com/u/boruok)\ **Post date:** [September 9, 2026, 12:07pm UTC](https://forum.defold.com/t/removing-32-bit-windows-support-and-separate-lua-states/83211/5 "2026-09-09T12:07:21Z")
do i understand correctly: now devs can, for example, call _ **go** _ functions from _ **gui** _ scripts and versa? ---
**Author:** ![AGulev](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/agulev/32/4541_2.png) [@AGulev](https://forum.defold.com/u/AGulev)\ **Post date:** [September 9, 2026, 12:34pm UTC](https://forum.defold.com/t/removing-32-bit-windows-support-and-separate-lua-states/83211/6 "2026-09-09T12:34:48Z")
No, it’s not related. `script.shared_state` controls whether game object scripts, GUI scripts, and render scripts share one Lua state, including global variables and loaded Lua modules. In 1.14.0, they will always share one state, so the setting will be removed. Each script instance will still have its own `self`. ---
**Author:** ![britzl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/britzl/32/23_2.png) [@britzl](https://forum.defold.com/u/britzl)\ **Post date:** [September 9, 2026, 2:16pm UTC](https://forum.defold.com/t/removing-32-bit-windows-support-and-separate-lua-states/83211/7 "2026-09-09T14:16:02Z")
It should be extremely rare for anyone to have `script.shared_state` unchecked. It has been checked as default for a very very long time. I’d say that 99.99% of all developers won’t notice any difference.