Support Windows platform

[kiennq]

I have a fork that adds Windows support as well here https://github.com/kiennq/ghostel

It's bit messy now and contain more than just Windows support:

• Windows console support via conpty-module + optimization so that it can perform better than vterm on Windows.
• Dynamic reloading emacs module without restating Emacs via dyn-loader-module
• Offer to download prebuilt binary version with simpler version schema (based on min support version and module version), no need to use package to parse for version anymore
• Use only build.zig for building, no need to use build.sh anymore

Do you think these are something that can be accepted here? I can clean up some parts as well

[ISouthRain]

@kiennq
Hello !!
I have been following your kiennq/ghostel for a long time. Can kiennq/ghostel be used on Windows now?
However, every time I test kiennq/ghostel using M-x ghostel will cause Emacs to crash.

If possible, I can provide more test logs, please guide me how to use kiennq/ghostel on Windows ???

[kiennq]

Can you try with this config?

(use-package ghostel
  :defer t
  :custom
  (ghostel-shell "pwsh")
  (ghostel-github-release-url "https://github.com/kiennq/ghostel/releases"))

We need to set the github-release-url so it downloads from my prebuilt binary.
I've been using ghostel for a while, it's quite stable now.
Sometimes it might crash if you run ghostel after ghostel-reload-module though. I haven't been able to reliable repro that one so no fix for that yet

[dakra]

Thank you very much @kiennq

I would like to help support windows, but looking at the diff of your fork the "5,035 additions and 1,511 deletions"
scare me a little bit. I didn't look much closer into it yet.

If all of those can maybe done in a way that would be easily reversible for me in case you're not around
anymore and/or I can't/don't want to support Windows anymore (because of too many Windows bugs in ghostel or something) etc that would be a big bonus.

So I imagine a vendored conpty module, extra build step and some (minimal) changes in the main elisp and zig code.
That way, if in some unknown future, I get flooded with ghostel Windows bugs and can't fix them myself I could just drop Windows support again without too much hassle.

But I'm willing to help landing it here.

If you could prepare one (or many?) PRs, I'll have a look.
Another question is, would you be willing to have a look at windows-bugs that come up here in the future?

Dynamic reloading emacs module without restating Emacs via dyn-loader-module

Hmm. Does that have any drawbacks? It sounds nice for developing but the zig code actually doesn't change that often and I think users also don't really update the native-module that much.
So if this has any drawbacks or is hard to maintain code I would say it's not necessary?
But I'm open. Maybe create a separate PR to discuss?

Offer to download prebuilt binary version with simpler version schema

Simpler how? getting the package version is only basically only (lm-header "Version"), which is not that complex ;)

Use only build.zig for building, no need to use build.sh anymore

sounds useful.

Thanks again for your effort so far ❤️

[kiennq]

I would like to help support windows, but looking at the diff of your fork the "5,035 additions and 1,511 deletions"
scare me a little bit. I didn't look much closer into it yet.

The changes are mostly from the emacs-module.h header I copied from Emacs to this. So that we can build without having a source code/installation of Emacs lying around. That will cut a bit time when build release since we don't need to install Emacs.
Another large part is from the new regression tests are being added as well.

Another question is, would you be willing to have a look at windows-bugs that come up here in the future?

Yes, I can do that.

Dynamic reloading emacs module without restating Emacs via dyn-loader-module

Hmm. Does that have any drawbacks? It sounds nice for developing but the zig code actually doesn't change that often and I think users also don't really update the native-module that much. So if this has any drawbacks or is hard to maintain code I would say it's not necessary? But I'm open. Maybe create a separate PR to discuss?

Sure. The idea for this is very simple, we have a stable dyn-loader-module that expose a generic interface where each sub module (for example ghostel-module) can register elisp functions with that. The dyn-loader-module will forward those functions to elisp and it can unload the submodule, load the new one without restarting. The sub-module's required changes are very simple, instead of registering functions with emacs, the sub-module registers that with dyn-loader-module.
I found it's quite useful especially when I don't want to restart Emacs.

Simpler how? getting the package version is only basically only (lm-header "Version"), which is not that complex ;)

That ties the release version on Github with the Elisp package version. By simpler I mean just by-default download the min support version, which is declared in Elisp code. And with C-u, we allow the user to specify the version to download (has to be newer than min support version) or download the latest version. That allows to have more releases for bug fix without have to update the Elisp package.

[ISouthRain]

(use-package ghostel
:defer t
:custom
(ghostel-shell "pwsh")
(ghostel-github-release-url "https://github.com/kiennq/ghostel/releases"))

@kiennq

OS: Windows 10
Version: GNU Emacs 31.0.50 (build 1, x86_64-w64-mingw32) of 2025-09-05

I still cannot run kiennq/ghostel on Windows, perhaps because the ghostel--minimum-module-version is different and the .tar.xz download fails.
So I manually downloaded https://github.com/kiennq/ghostel/releases and copied the .dll/.json file to the ghostel directory. When everything loaded normally, Emacs crashed immediately when I used M-x ghostel. I used emacs -Q to start Emacs.

Am I missing any necessary steps???

[kiennq]

Windows 10 might be reason, also, what's the value of your ghostel-shell?
Btw, you can use C-u M-x ghostel-download-module and <RET>, it will download the latest module version.

[ISouthRain]

ghostel-shell?

I try ghostel-shell value is pwsh or powershell or emacs/cmdproxy.exe
They all have the same problem

[dakra]

@kiennq so I would say you can make a separate PR for each as they seem independent

• replacing build.sh with zig build
• the package version change (I'm still not sure I understand, but we can discuss in the PR)
• add windows support with conpty
• they dyn-loader-module (It does sound useful now in the beginning, but I'm wondering if it is really necessary longterm. We can discuss this also in that PR then).

You can also make them one by one if it makes it easier in case they build on each other.
I would imagine, 1 and 2 is fast discussed/merged while windows support may need a longer testing phase.

wdyt?

[kiennq]

ghostel-shell?

I try ghostel-shell value is pwsh or powershell or emacs/cmdproxy.exe They all have the same problem

Can you try to compile the module by your own to see if they're still crashing? There's command in ghostel that does compilation. You will need zig toolchains but they're easy to install

[ISouthRain]

@kiennq
Oh~~~
Thank you.
I download kiennq/ghostel releases I can already use kiennq/ghostel normally with emacs -q and emacs -Q.
However I cannot use my personal .emacs.d configuration using kiennq/ghostel,
I think one of my configurations conflicts with kiennq/ghostel

Result: kiennq/ghostel is ok

[kohnish]

I want to try it out but the download is failing for some reason, while our main branch is ok.
I'd appreciate a branch or commit I can merge that would only support windows without other unrelated refactors, also without carriage return. I can download the file manually for now.

[kiennq]

@kohnish, can you try with kiennq@3057248, the prebuilt version is https://github.com/kiennq/ghostel/releases/tag/v0.9.0.20.171f01
For the download, you will need to set url path. Trigger C-u M-x ghostel-download-module and press Enter to download the latest version, or you can enter the tag 0.9.0.20.171f01 there

(use-package ghostel
  :defer t
  :custom
  (ghostel-shell "pwsh")
  (ghostel-github-release-url "https://github.com/kiennq/ghostel/releases"))

[ISouthRain]

can you try with kiennq@3057248, the prebuilt version is https://github.com/kiennq/ghostel/releases/tag/v0.9.0.20.171f01

@kiennq

Very good!
Now ghostel is fully compatible with my configuration and there is no crash problem!!
Cool!!!

[kohnish]

@kiennq

Thanks a lot. For me, I get Module does not export an initialization function error. For some reasons, download doesn't still work, so I just placed dll files manually. It could be my setup issue as another user say it's working, so I'm debugging it now.

PS:
I also realised you are the maintainer of emacs with native-comp build for windows. It's really annoying to work with windows toolchains for me, I really appreciate your work.

[kiennq]

@kohnish can you try with these customizations?

(use-package ghostel
  :defer t
  :vc ....
  :custom
  (ghostel-github-release-url "https://github.com/kiennq/ghostel/releases"))

Then download with C-u M-x ghostel-download-module, it will prompt a tag, or you can just press Enter to download the latest version.