6 ms·

I ran into this trying to get into it about 3 weeks ago. I'm so used to things like npm, ruby gems, go packages, pip that it felt like a huge task just to get s

I ran into this trying to get into it about 3 weeks ago. I'm so used to things like npm, ruby gems, go packages, pip that it felt like a huge task just to get something built or settle on a way for me to build mine. Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. I wish I had stayed with it since college but now I feel I have to reach for something like Go or Rust just to get something shareable in reasonable time purely because of the tooling, whereas I would really like to use the C++ language itself specifically for working with win32.

lmm 8y ago
Making Rust work nicely with win32 is probably less effort (and more valuable) than getting enough momentum behind a good dependency manager for C++.
- ModernMech 8y ago
  Rust works great on Windows. I use it every day. Is there anything specifically you had in mind that needs to be improved? Off the top of my head there is some tooling work that needs to be done, but cargo and rustup handle compiling, versioning, and dependency management flawlessly imo.
  - tomsmeding 8y ago
    Person you're replying to probably means the win32 API, i.e. writing GUI applications for windows in Rust.
- Const-me 8y ago
  > work nicely with win32 is probably less effort Gonna be very hard to do. For the last 15+ years COM is essential part of WinAPI, and too many things in Rust conflict with COM: ownership, OOP, virtual tables, inheritance, they all too different. Not just in Rust, in all languages, actually. You only have 2 good choices for complex platform-dependent windows development: either C++, or a microsoft's language with COM support embedded deep in the runtime, like VB6 or VBScript or .NET.
  - pjmlp 8y ago
    Delphi, JavaScript, Python and C++ Builder as well.
    - Const-me 8y ago
      I think Delphi and C++ Builder were only good enough while WinAPI meant “C API”. JavaScript is OK for platform-independent development with electron. For platform-specific i.e. WinRT not that good, .NET is just better, and MS put the JS libraries in maintenance mode: https://github.com/winjs/winjs https://github.com/winjs/winjs Python was never good. I’ve tried using winapi through C interop a few times, didn’t like it at all despite what I did wasn’t even too complex.
      - pjmlp 8y ago
        Delphi and C++ Builder have first class support for COM and UWP. In fact, both had better COM support before VB migrated from VBX to COM with VB 6.0. JavaScript has first class support on UWP. Of course WinJS is in maintenance BB mode. The future of JavaScript on UWP are PWA apps, with direct access to UWP APIs, no more need for WinJS, which was a Windows 8 library. Python has supported COM with help from PyWin32 since ages. Hardly any different from VBScript.
        Const-me 8y ago
        > first class support for COM and UWP When I search “Delphi DirectX”, I only find some Russian website last updated in 2009 and offering Direct3D 10.1 bindings. The newest one is 12, the oldest supported is 11.2. When I search “Delphi Media Foundation” it’s better, finds bindings updated 4 years ago. These COM-based technologies are among reasons why I sometimes still pick C++ even for new projects. Also, in both cases just bindings are not enough, the frameworks are complex, need code samples, stackoverflow community, sometimes books, etc. There’re tons of resources on using these from C++, many from C#, very few for the rest of the languages. > JavaScript has first class support on UWP Win32 GDI also has first class support on Win10, just because it’s supported doesn’t mean it will go anywhere. I have doubts MS will continue with that support, they haven’t achieved much and need to do something else, e.g. include CEF in the OS. > Hardly any different from VBScript. The difference is that VBScript _is_ COM. All VBScript variables are VARIANT, all strings are VARIANT of VT_BSTR type, and all objects are IDispatch. The interop is not required, COM is already native to the runtime. I can write a COM server in a page long text file with *.wsc extension and VBScript inside, register it with regsvr32.exe, and consume from any language, e.g. `#import "progid:..."` in VC++. I’m not sure you can do same in Python.
- nicoburns 8y ago
  I have high hopes for C++ modules. Seems like that could be a good catalyst for a standard C++ package manager.
- seertaak 8y ago
  I'm sure Rust works great :) But vcpkg was made by Microsoft and I suspect is rather easy to get working on that platform. On the other hand, I've used conan and had no problem e.g. getting FFmpeg working. And, thanks to conan's awesomeness, I can even make it work with clang on windows -- so that e.g. I can use all the latest c++17 features on a library like Boost.Hana and range-v3 (of Eric Niebler fame).
- pjmlp 8y ago
  Rust is still miles away from providing any useful COM/UWP tooling.
radarsat1 8y ago
> Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. Honestly this is something that apt (et al.) make so easy on Linux distros that when you move to Mac or Windows you just have hard time believing people still in 2018 have to _deal with this shit_ (installing libraries and their headers by downloading each one separately and running an "installer" and trying to figure out where it put everything) Like, why. It's one of the principle things keeping me away from developing on Windows for the last 10 or 15 years, the absolute lack of standards with regards to dev package management. Every time I decide I need to get something working on Windows it's an incredible pain in the ass compared to Ubuntu. Oh, now go to THIS website and download this installer and run it, now this one, now this one. And figure out for each one where it decided to put the headers. Now copy the DLLs around, etc. (Yes, there is system32 and Program Files but installers don't adhere to this by any means, and discovery via a build system is not given.) It's just barely worth it, and people only put up with it because of the huge user base. Honestly, for small projects I've found it easier to install MingW32 under Linux and cross-compile instead of working on Windows, it's that much of a pain. At least Mac has Homebrew and Windows has a couple of good solutions now I guess (chocolatey, who came up with that name), but they are not officially supported and that is sad. I understand, they don't want to pay an army of people to package open source software full time, which effectively is what keeps Debian and Fedora going.. but they should. I would say it's one of principle reasons then end up doing something like providing an Ubuntu environment on Windows .. it's not just that people wanted a Unix-like environment, it's that they wanted _package management_.
- xnyan 8y ago
  Windows continues to move in the right direction with package management. Your comment "not officially supported" may not be correct depending on your definition of official. Package management is native in win10 with OneGet, and PMs like scoop have been improving in quality and reliability to the point that I don't even think about them anymore. I do agree that there is a lot of room for standardizing tool chain and dependency install workflows, but the tools themselves are of high quality now imo.
mattnewport 8y ago
Have you looked at vcpkg? It's the simplest way to use third party libraries on Windows in my experience. Many popular open source libraries are supported out the box by vcpkg now.
- sl1ck731 8y ago
  I didn't but some of the libraries I needed at the time don't appear to be present. The reason I wanted to use C++ specifically was API hooking and the Windows ETW api. I don't see any of the projects like Detours present so unfortunately it wouldn't have helped me in this case. It does look promising but because of the mess I'll probably gravitate to another language if I don't need to consume such a low level API.
seertaak 8y ago
Someone else has mentioned vcpkg. Another project that gets you closer to Rust or Go in this respect is conan, which I really enjoy using. It's still not as polished as other package managers (e.g. maven), but for a lot of very useful libraries, on a reasonable platform (recent OS, recent compiler) and for most important libraries (FFmpeg, boost, abseil, range-v3, the list goes on...) you can just add a single line to your conanfile with the version you want and off you go. And remember -- a lot of the complexity comes from historical reasons AND also allow you to, e.g. run on, say an Atmel 328p or other microcontroller. So the complexity is partly from having such a wide target area.

lmm 8y ago

Making Rust work nicely with win32 is probably less effort (and more valuable) than getting enough momentum behind a good dependency manager for C++.

ModernMech 8y ago
Rust works great on Windows. I use it every day. Is there anything specifically you had in mind that needs to be improved? Off the top of my head there is some tooling work that needs to be done, but cargo and rustup handle compiling, versioning, and dependency management flawlessly imo.
- tomsmeding 8y ago
  Person you're replying to probably means the win32 API, i.e. writing GUI applications for windows in Rust.
Const-me 8y ago
> work nicely with win32 is probably less effort Gonna be very hard to do. For the last 15+ years COM is essential part of WinAPI, and too many things in Rust conflict with COM: ownership, OOP, virtual tables, inheritance, they all too different. Not just in Rust, in all languages, actually. You only have 2 good choices for complex platform-dependent windows development: either C++, or a microsoft's language with COM support embedded deep in the runtime, like VB6 or VBScript or .NET.
- pjmlp 8y ago
  Delphi, JavaScript, Python and C++ Builder as well.
  - Const-me 8y ago
    I think Delphi and C++ Builder were only good enough while WinAPI meant “C API”. JavaScript is OK for platform-independent development with electron. For platform-specific i.e. WinRT not that good, .NET is just better, and MS put the JS libraries in maintenance mode: https://github.com/winjs/winjs https://github.com/winjs/winjs Python was never good. I’ve tried using winapi through C interop a few times, didn’t like it at all despite what I did wasn’t even too complex.
    - pjmlp 8y ago
      Delphi and C++ Builder have first class support for COM and UWP. In fact, both had better COM support before VB migrated from VBX to COM with VB 6.0. JavaScript has first class support on UWP. Of course WinJS is in maintenance BB mode. The future of JavaScript on UWP are PWA apps, with direct access to UWP APIs, no more need for WinJS, which was a Windows 8 library. Python has supported COM with help from PyWin32 since ages. Hardly any different from VBScript.
      - Const-me 8y ago
        > first class support for COM and UWP When I search “Delphi DirectX”, I only find some Russian website last updated in 2009 and offering Direct3D 10.1 bindings. The newest one is 12, the oldest supported is 11.2. When I search “Delphi Media Foundation” it’s better, finds bindings updated 4 years ago. These COM-based technologies are among reasons why I sometimes still pick C++ even for new projects. Also, in both cases just bindings are not enough, the frameworks are complex, need code samples, stackoverflow community, sometimes books, etc. There’re tons of resources on using these from C++, many from C#, very few for the rest of the languages. > JavaScript has first class support on UWP Win32 GDI also has first class support on Win10, just because it’s supported doesn’t mean it will go anywhere. I have doubts MS will continue with that support, they haven’t achieved much and need to do something else, e.g. include CEF in the OS. > Hardly any different from VBScript. The difference is that VBScript _is_ COM. All VBScript variables are VARIANT, all strings are VARIANT of VT_BSTR type, and all objects are IDispatch. The interop is not required, COM is already native to the runtime. I can write a COM server in a page long text file with *.wsc extension and VBScript inside, register it with regsvr32.exe, and consume from any language, e.g. `#import "progid:..."` in VC++. I’m not sure you can do same in Python.
nicoburns 8y ago
I have high hopes for C++ modules. Seems like that could be a good catalyst for a standard C++ package manager.
seertaak 8y ago
I'm sure Rust works great :) But vcpkg was made by Microsoft and I suspect is rather easy to get working on that platform. On the other hand, I've used conan and had no problem e.g. getting FFmpeg working. And, thanks to conan's awesomeness, I can even make it work with clang on windows -- so that e.g. I can use all the latest c++17 features on a library like Boost.Hana and range-v3 (of Eric Niebler fame).
pjmlp 8y ago
Rust is still miles away from providing any useful COM/UWP tooling.

radarsat1 8y ago

> Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. Honestly this is something that apt (et al.) make so easy on Linux distros that when you move to Mac or Windows you just have hard time believing people still in 2018 have to _deal with this shit_ (installing libraries and their headers by downloading each one separately and running an "installer" and trying to figure out where it put everything) Like, why. It's one of the principle things keeping me away from developing on Windows for the last 10 or 15 years, the absolute lack of standards with regards to dev package management. Every time I decide I need to get something working on Windows it's an incredible pain in the ass compared to Ubuntu. Oh, now go to THIS website and download this installer and run it, now this one, now this one. And figure out for each one where it decided to put the headers. Now copy the DLLs around, etc. (Yes, there is system32 and Program Files but installers don't adhere to this by any means, and discovery via a build system is not given.) It's just barely worth it, and people only put up with it because of the huge user base. Honestly, for small projects I've found it easier to install MingW32 under Linux and cross-compile instead of working on Windows, it's that much of a pain. At least Mac has Homebrew and Windows has a couple of good solutions now I guess (chocolatey, who came up with that name), but they are not officially supported and that is sad. I understand, they don't want to pay an army of people to package open source software full time, which effectively is what keeps Debian and Fedora going.. but they should. I would say it's one of principle reasons then end up doing something like providing an Ubuntu environment on Windows .. it's not just that people wanted a Unix-like environment, it's that they wanted _package management_.

xnyan 8y ago
Windows continues to move in the right direction with package management. Your comment "not officially supported" may not be correct depending on your definition of official. Package management is native in win10 with OneGet, and PMs like scoop have been improving in quality and reliability to the point that I don't even think about them anymore. I do agree that there is a lot of room for standardizing tool chain and dependency install workflows, but the tools themselves are of high quality now imo.

mattnewport 8y ago

Have you looked at vcpkg? It's the simplest way to use third party libraries on Windows in my experience. Many popular open source libraries are supported out the box by vcpkg now.

sl1ck731 8y ago
I didn't but some of the libraries I needed at the time don't appear to be present. The reason I wanted to use C++ specifically was API hooking and the Windows ETW api. I don't see any of the projects like Detours present so unfortunately it wouldn't have helped me in this case. It does look promising but because of the mess I'll probably gravitate to another language if I don't need to consume such a low level API.

seertaak 8y ago

Someone else has mentioned vcpkg. Another project that gets you closer to Rust or Go in this respect is conan, which I really enjoy using. It's still not as polished as other package managers (e.g. maven), but for a lot of very useful libraries, on a reasonable platform (recent OS, recent compiler) and for most important libraries (FFmpeg, boost, abseil, range-v3, the list goes on...) you can just add a single line to your conanfile with the version you want and off you go. And remember -- a lot of the complexity comes from historical reasons AND also allow you to, e.g. run on, say an Atmel 328p or other microcontroller. So the complexity is partly from having such a wide target area.