[PSA] Moving away from .bat files on Windows

[Sam Clegg]

;tldr; I am hoping to replace the current .bat files with .exe files on Windows. 

I'm hoping to land this change today: https://github.com/emscripten-core/emscripten/pull/24858

It replaces the `.bat` files we currently use to launch emscripten python tools with a small windows executable.

There are some concerns this could trigger false positives in security scanners so its possible this will get reverted, but I would love to get some early feedback from windows users.

If you are a Windows user, please try `emsdk install tot` once this lands (I'll reply here when it does, assuming it sticks).

cheers,

sam

[Sam Clegg]

This change has now been part of emscripten and emsdk for 3 releases (6.0.0, 6.0.1, and 6.0.2).

Have any Windows users experienced any issues with this?   Any unexpected fallout from using `.exe` files?

cheers,

sam

[Mike]

Sure - one problem with using an exe instead of a BAT file is that now whenever someone has to make changes to that particular .exe file, they have to rebuild it from source which can be difficult to replicate if they are using Linux or other OS and requires massive libraries with all  sorts of dependencies etc, whereas if its a .bat file its easy to maintain and transparent for anyone who wants to see the what is going on behind the scenes. If its an exe also malware could replace that .exe file with an infected file and subsequently infect your webassembly output by injecting any number of tracking, vandalism, or secret entrypoint that can be used for XSS such as hosting spam content when a secret GET parameter is provided or something like that, it could even turn your website into a host that helps to distribute malware without leaving a trail as to where it came from..

.bat files have a lot fewer scary things that can go wrong, and if they do go wrong, at least you can open it up and figure out what went wrong.  

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29YQgXdWBaWqjwFOgMm0xWivUOdObBw%3DmzDFVW2Q0tvWA%40mail.gmail.com.

[Justin Nolan]

I had issues in the past with .bat files when using cmake with the emscripten toolchain file to build when using git bash to invoke the build, using the normal windows terminal worked.
That issue is now gone with the .exe files as they dont care about what shell invokes them. 

[Sam Clegg]

On Thu, Jul 9, 2026 at 7:46 PM Mike <sep...@gmail.com> wrote:

Sure - one problem with using an exe instead of a BAT file is that now whenever someone has to make changes to that particular .exe file, they have to rebuild it from source which can be difficult to replicate if they are using Linux or other OS and requires massive libraries with all  sorts of dependencies etc, whereas if its a .bat file its easy to maintain and transparent for anyone who wants to see the what is going on behind the scenes. If its an exe also malware could replace that .exe file with an infected file and subsequently infect your webassembly output by injecting any number of tracking, vandalism, or secret entrypoint that can be used for XSS such as hosting spam content when a secret GET parameter is provided or something like that, it could even turn your website into a host that helps to distribute malware without leaving a trail as to where it came from..

.bat files have a lot fewer scary things that can go wrong, and if they do go wrong, at least you can open it up and figure out what went wrong.  

Thanks Mike,

I do understand the general objection here that `.exe` files are more opaque and harder to work on. 

Regarding the "whenever someone has to make changes to that particular .exe file" issue, one thing we did to mitigate that is that all the `.exe` files are identical (byte-for-byte) and really do not do anything clever, so should almost never need to change.  All they do is launch python.exe, and then all the logic of emscripten still lives in python code.  See https://github.com/emscripten-core/emscripten/tree/main/tools/pylauncher.   Because of this I don't think anyone would ever need/want to make changes to any sinlge/particular exe file, since there is no app-specific logic within the exe to change.

Regarding the "malware could infect the exe" argument, wouldn't that also apply to any of the exe's already involved in the toolchain (e.g. node.exe, python.exe, clang.exe, etc)?

I hope this helps to alleviate some of your concern here?

cheers,

sam

On Tue, Jul 7, 2026 at 1:56 PM 'Sam Clegg' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

This change has now been part of emscripten and emsdk for 3 releases (6.0.0, 6.0.1, and 6.0.2).

Have any Windows users experienced any issues with this?   Any unexpected fallout from using `.exe` files?

cheers,

sam

On Thu, Feb 19, 2026 at 2:59 PM Sam Clegg <s...@google.com> wrote:

;tldr; I am hoping to replace the current .bat files with .exe files on Windows. 

I'm hoping to land this change today: https://github.com/emscripten-core/emscripten/pull/24858

It replaces the `.bat` files we currently use to launch emscripten python tools with a small windows executable.

There are some concerns this could trigger false positives in security scanners so its possible this will get reverted, but I would love to get some early feedback from windows users.

If you are a Windows user, please try `emsdk install tot` once this lands (I'll reply here when it does, assuming it sticks).

cheers,

sam

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29YQgXdWBaWqjwFOgMm0xWivUOdObBw%3DmzDFVW2Q0tvWA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CACD-exvC1yo2gDEoc6yS1gWmd7ORCkPMQ4viL6%2BhtNZO6Um4ig%40mail.gmail.com.

[Mike]

I would say if the exe files are just doing something super simple like calling python.exe, then the risk of them being malware is in fact no greater than the risk of python.exe being malware or the python scripts themselves containing hidden malware, which would be a much easier place to target than injecting into an exe file that is just a launcher. 

I guess it all comes down to risk versus reward. There is some risk, but its probably minimal.. something like an exe file that launches a different script might be one potential way that can be misused. 

I would say from a security standpoint, making emscripten into more of a system package similar to the windows C# compiler would be the best move. If it gets installed with elevated privileges and lives in Program Files would make it as secure as anything else on Windows. This would alleviate most of the issues with malware hiding in the emsdk,and could probably be done with relatively little effort with today's access to vast resources of information. 

Another issue with making it into .exe files is having to package additional .dll files to make them run.  While this might be very little, often, on Windows running .exe files requires a whole bunch of additional libraries to already be installed due to  its massive dependency hierarchy. I would say if you do package .exe files, make sure to include all of the required libraries or users will be trying to compile and just getting error after error because they didn't install msvcrun-6,0 runtime or whatever.

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_rXM2cDQNeqCC6DzDzt0RJ_b4x7CxSEH7XSNszVf5cBw%40mail.gmail.com.

[Sam Clegg]

On Fri, Jul 10, 2026 at 11:36 AM Mike <sep...@gmail.com> wrote:

I would say if the exe files are just doing something super simple like calling python.exe, then the risk of them being malware is in fact no greater than the risk of python.exe being malware or the python scripts themselves containing hidden malware, which would be a much easier place to target than injecting into an exe file that is just a launcher. 

I guess it all comes down to risk versus reward. There is some risk, but its probably minimal.. something like an exe file that launches a different script might be one potential way that can be misused. 

I would say from a security standpoint, making emscripten into more of a system package similar to the windows C# compiler would be the best move. If it gets installed with elevated privileges and lives in Program Files would make it as secure as anything else on Windows. This would alleviate most of the issues with malware hiding in the emsdk,and could probably be done with relatively little effort with today's access to vast resources of information. 

Another issue with making it into .exe files is having to package additional .dll files to make them run.  While this might be very little, often, on Windows running .exe files requires a whole bunch of additional libraries to already be installed due to  its massive dependency hierarchy. I would say if you do package .exe files, make sure to include all of the required libraries or users will be trying to compile and just getting error after error because they didn't install msvcrun-6,0 runtime or whatever.

WRT to this final point, we did go to quite a lot of effort to avoid runtime dll dependencies.   

See https://github.com/emscripten-core/emscripten/blob/eadd74a970698350e5b523c9d4a840a3d3e58f1b/tools/pylauncher/pylauncher.c#L13-L14

```
 * Built with /NODEFAULTLIB linking only against ucrt.lib (ucrtbase.dll) to
 * avoid any dependency on a specific Visual C++ Redistributable version.
```

We even built with `/ENTRY:launcher_main /SUBSYSTEM:CONSOLE` which bypassed the normal crt startup that comes before C `main`.

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CACD-exv9J_RU_A_uStvenL2vT4HgPzkEAUA-8A%2Bnt1GGQ5uXtw%40mail.gmail.com.