4 ms·

Wtf? Why doesn't anything like this exist today? Windows doesn't have anyway to create an .exe (that I'm aware of) besides C#, C++, turbo basic and that's about

Wtf? Why doesn't anything like this exist today? Windows doesn't have anyway to create an .exe (that I'm aware of) besides C#, C++, turbo basic and that's about it. All I really want is a way to write terse code and release it to other users without installation of a runtime ...etc. I can't even distribute PS, because you can't guarantee another user has the right version.

cagey 10y ago
I certainly agree with your sentiment. Yet I'm unsure that even C# or C++ _by default_ builds .EXE files that can be copied onto another (same OS) machine and run successfully (for C++ this is almost always possible, but IIRC not default build behavior). "What happened" was industry-wide standardization on dynamic-linking of prerequisite (library) code (IOW, this code stays in separate DLL files typically stored in system-global locations), leading to the need for "installer" software whose purpose (I presume; I've entirely avoided dealing with that stuff) is to ensure that all prerequisite dynamic libraries are upgraded to the minimum version needed by the SW being installed, replaces any old version(s) of the program with the new, and modifies the Windows Registry in various and sundry ways (can you say "system-global variables run amok"?). The solution which I prefer is to build static-linked .EXEs (binaries) instead of dynamic-linked. Convincing toolchains to do this is a small exercise for the reader. OBTW: I think go (golang) static-links by default. I stopped using TAWK compiler when I discovered Lua (5.1; IMHO a substantially better language than TAWK (this is not a criticism of TAWK)). I even went so far as to commission a "Lua Compiler" for Win32 which behaved almost identically to the TAWK compiler; I used this with great success for a few years. Unfortunately it was an internal tool which I lost access to when I departed that employer. P.S. IIRC Borland Delphi also builds static-linked EXEs by default. I wrote one Delphi 2 (Win NT 4.0 era) program whose source code I've kinda lost track of which still runs fine on Win10 x64. TAWK and Lua are more productive languages than Delphi/Pascal, and it's trivially easy to add your own C library functions to Lua (for improved performance or added functionality), so I gravitated toward an overall preference for Lua.
- throwaway7645 10y ago
  Yea, but neither Lua or LuaJIT can make a true binary without some hack where you package up the interpreter as well.
  - etiene 10y ago
    It's not complicated and the interpreter is super light though
- throwaway7645 10y ago
  Forgot to say thanks for the excellent reply!
e12e 10y ago
Golang? Actually has pretty decent windows support (although some projects tend to assume Unix paths etc). And freepascal, nim. Perhaps ocaml (but might require some magic to generate a standalone exe? I belive unison is available as just an exe file?). Ed: and rust?
- throwaway7645 10y ago
  Golang isn't good at fast development although that is a good point. Nim is still pretty immature. OCaml is great on Unix, but appears to be a pain on Windows unless you like Cygwin.

cagey 10y ago

I certainly agree with your sentiment. Yet I'm unsure that even C# or C++ _by default_ builds .EXE files that can be copied onto another (same OS) machine and run successfully (for C++ this is almost always possible, but IIRC not default build behavior). "What happened" was industry-wide standardization on dynamic-linking of prerequisite (library) code (IOW, this code stays in separate DLL files typically stored in system-global locations), leading to the need for "installer" software whose purpose (I presume; I've entirely avoided dealing with that stuff) is to ensure that all prerequisite dynamic libraries are upgraded to the minimum version needed by the SW being installed, replaces any old version(s) of the program with the new, and modifies the Windows Registry in various and sundry ways (can you say "system-global variables run amok"?). The solution which I prefer is to build static-linked .EXEs (binaries) instead of dynamic-linked. Convincing toolchains to do this is a small exercise for the reader. OBTW: I think go (golang) static-links by default. I stopped using TAWK compiler when I discovered Lua (5.1; IMHO a substantially better language than TAWK (this is not a criticism of TAWK)). I even went so far as to commission a "Lua Compiler" for Win32 which behaved almost identically to the TAWK compiler; I used this with great success for a few years. Unfortunately it was an internal tool which I lost access to when I departed that employer. P.S. IIRC Borland Delphi also builds static-linked EXEs by default. I wrote one Delphi 2 (Win NT 4.0 era) program whose source code I've kinda lost track of which still runs fine on Win10 x64. TAWK and Lua are more productive languages than Delphi/Pascal, and it's trivially easy to add your own C library functions to Lua (for improved performance or added functionality), so I gravitated toward an overall preference for Lua.

throwaway7645 10y ago
Yea, but neither Lua or LuaJIT can make a true binary without some hack where you package up the interpreter as well.
- etiene 10y ago
  It's not complicated and the interpreter is super light though
throwaway7645 10y ago
Forgot to say thanks for the excellent reply!

e12e 10y ago

Golang? Actually has pretty decent windows support (although some projects tend to assume Unix paths etc). And freepascal, nim. Perhaps ocaml (but might require some magic to generate a standalone exe? I belive unison is available as just an exe file?). Ed: and rust?

throwaway7645 10y ago
Golang isn't good at fast development although that is a good point. Nim is still pretty immature. OCaml is great on Unix, but appears to be a pain on Windows unless you like Cygwin.