8 ms·

https://github.com/robmikh/minesweeper-rs https://github.com/robmikh/minesweeper-rs - I just love how they brilliantly avoided mixing up C++/COM things into thi

https://github.com/robmikh/minesweeper-rs https://github.com/robmikh/minesweeper-rs - I just love how they brilliantly avoided mixing up C++/COM things into this. Tough one to pull when you're dealing with bindings for a foreign language. The code looks fairly standard Rust (except maybe for the winrt::import that looks like Go?). > If you are familiar with Rust, you will notice this looks far more like Rust than it looks like C++ or C#. Notice the snake_case on module and method names and the ? operator for error propagation. Developing on and now for Windows just keeps getting better.

pathartl 6y ago
It seems like they're doing all they can to get developers on their platform. Not to establish Windows developers like they have in the past, but to have others see Windows as just another platform. We're reaching a revolution from moving from x86 to ARM and I think the more Microsoft positions themselves like this, the less likely they are to be left in some weird compatibility limbo. As weird as this sounds, I feel more confident with Microsoft being able to do a successful transition to ARM than Apple at this point.
- pianoben 6y ago
  In fact, the _have_ transitioned to ARM, way back around the time of the first Surface tablet. Windows and Office have been running on ARM since at least, what, 2012?
  - loeg 6y ago
    Windows NT in 2000? I guess ARM was not a going concern at the time, but Windows was remarkably portable in 2000 before the dark decade of more or less exclusively Wintel.
    - zrm 6y ago
      https://archive.org/details/Microsoft_Windows_NT_Server_Version_4.0_94373_Microsoft_1996 https://archive.org/details/Microsoft_Windows_NT_Server_Vers... "Disc contains code to run on Windows NT-compatible x86, Pentium, MIPS, R4x00, Alpha, PowerPC and Pentium Pro systems"
  - pnako 6y ago
    Way before that they had ARM-based Pocket PCs running Windows CE (or Windows Mobile).
  - jupp0r 6y ago
    Windows itself has never been the problem, but the Software that’s running on it.
- VWWHFSfQ 6y ago
  It will be very difficult until Windows is POSIX-compatible. Whatever that means, I don't know. But it can't just be the Windows Subsystem for Linux. The whole OS needs to have POSIX compatibilities.
  - wongarsu 6y ago
    Windows NT used to have a POSIX subsystem [1] that applications could use instead of the Win32 subsystem. So the Windows NT kernel is designed with the option of POSIX compatibility. Arguably the Subsystem for Linux is the current successor of the POSIX subsystem, providing POSIX compatible access to the kernel along with a POSIX compatible shell and UNIX commands. Obviously the Win32 subsystem isn't POSIX compatible, but I'm not sure why we would want that. 1: https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
    - jacobush 6y ago
      That subsystem was just so they could tick off the “POSIX” box for Department of Defence.
      - pjmlp 6y ago
        That was one of many, then came SFU, followed by SUA. GNU/Linux users should be happy that old Microsoft didn't bother to do that much with POSIX subsystem. Had they actually invested into keeping it up to date, and many of us on PC land would never bothered with FOSS UNIX clones.
        jacobush 6y ago
        Yeah, that may be true, but on the other hand, had they made it useable, portabilith with other Unix would have been a simpler option. Simpler than Win32 + Unix portability in any case. Or in some cases, software would have been ported to Win32 at all.
        6y ago
- GordonS 6y ago
  Windows is my daily driver, and I spend most of my time at work these days building dotnet core applications for Linux on both x64 and ARM. It's a great dev experience Seeing what was coming with cloud and making .NET cross-platform was very well timed.
- DeathArrow 6y ago
  Microsoft tried countless times to move to Arm. The most recent efforts are with their Surface Pro X, their SQ1 CPU and pushing Qualcomm to release Snapdragon 8cx CPU for ARM laptops. But most software development companies didn't care enough to recompile their software for Arm and running X86 software in emulation is not exactly a good experience.
Koshkin 6y ago
> brilliantly avoided mixing up C++/COM I remember VB6 was also exceptionally good at this.
- KeBugCheckEx 6y ago
  Actually a lot in COM was made to work on vb. COM string type is BSTR which stands for Basic STRing.
- pjmlp 6y ago
  COM is both an evolution of VBX and a subset of OLE 2.0. .NET was going to be what UWP is now, an evolution of COM, but then Java happened, and they went with something similar instead. There are some references to how this all happened in the story of F# evolution, given that Don Syme was part of the team since the early days.
peatmoss 6y ago
How can we bring this to Linux/BSD? Specifically the GUI layer? I’ve lamented that Linux desktop world has been fragmented and alien as compared to other major environments. I used to think that things would have been better if we had chased GNUStep and source compatibility with macOS. I feel like the non-GUI userland in Linux is best in class and is effectively a given for any server deployment. But all the developers I know cobble together a mediocre Linux-like environment on macOS so they can have a first-class desktop environment and an okay development environment. On the other hand I read about people using Windows as development environment by using WSL. I feel like Linux will never organically gain critical mass for a desktop environment—substantial source compatibility with some major platform seems like the way to go. How are the Windows APIs vs the Cocoa APIs these days? Assuming source compatibility could help boost desktop Linux’s fortunes, is Windows or Cocoa a better target? Does consideration of iOS change the calculus?
- pjmlp 6y ago
  It is already available, it is called GObject, KParts, D-Bus. If the community has embraced a proper desktop eco-system around them, like the component vendors on other platforms, they aren't going to start now. I surely don't see job offers for Linux/BSD GUI toolkits as I see for Apple, Microsoft and Google ones. WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do the same. For traditional Windows developers it doesn't really matter. PowerShell + Windows Terminal is where the action is.
  - fluffything 6y ago
    > WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do the same. Do you know many people that used to do this with macOS and are now using Windows ? Like, oh boy, I tried, but after 4 months I ended up back with macOS.
    - sfifs 6y ago
      In my experience, one of the the problems is that Macs are hilariously underpowered for many modern dev and analytics use cases. So the workaround is to work off remote machines/clusters over web interfaces/SSH but for many development use cases that's just slow and clunky - the have merit more in productionising. The series of hardware clusterfucks on Mac haven't helped ether. So I've seen Mac users who work in these areas get sick of the issues and limitations and switch to Win 10 + sometimes WSL. The people remaining with Macs are executive suite (who go for iPad pros) and account execs who do sales where it looks cool to go pull out a Mac. However even there people are increasingly looking dumb when they want to present something and go on 5 min dongle troubleshooting hunt because Mac killed HDMI and VGA ports and start their presentation appearing incompetent. Sometimes over web screen shares, only the desktop shows and not the applications. By refusing to focus on hardware/software quality and power users, Apple has lost the game on high end.
masklinn 6y ago
> except maybe for the winrt::import that looks like Go? It looks to be a pretty extensive codegen hook, generating bindings to the referenced runtime components on the fly based on the module metadata it finds on the system. Apparently the C++ version uses IDL and an explicit codegen step instead: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt#windows-runtime-component-cwinrt https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...
- steveklabnik 6y ago
  It's a really intriguing approach; most use "build.rs" to do codegen.
  - masklinn 6y ago
    Seems sensible though, the build.rs solution would require every project using rust/winrt to have a build.rs and code to load & codegen the modules (probably copy/pasted), so it'd be a lot more work for users of rust/winrt, though I guess it'd be less magic.
    - steveklabnik 6y ago
      Oh yeah, I agree. I’m really interested to see if this approach would work better than build.rs for some other projects too.
      - ratmice 6y ago
        Bah... This seems like exactly the kind of thing that makes dependency tracking, and sandboxing compilation harder.
        steveklabnik 6y ago
        Why? I'm not an expert here, but it seems basically the same to me.
      - 6y ago

pathartl 6y ago

It seems like they're doing all they can to get developers on their platform. Not to establish Windows developers like they have in the past, but to have others see Windows as just another platform. We're reaching a revolution from moving from x86 to ARM and I think the more Microsoft positions themselves like this, the less likely they are to be left in some weird compatibility limbo. As weird as this sounds, I feel more confident with Microsoft being able to do a successful transition to ARM than Apple at this point.

pianoben 6y ago
In fact, the _have_ transitioned to ARM, way back around the time of the first Surface tablet. Windows and Office have been running on ARM since at least, what, 2012?
- loeg 6y ago
  Windows NT in 2000? I guess ARM was not a going concern at the time, but Windows was remarkably portable in 2000 before the dark decade of more or less exclusively Wintel.
  - zrm 6y ago
    https://archive.org/details/Microsoft_Windows_NT_Server_Version_4.0_94373_Microsoft_1996 https://archive.org/details/Microsoft_Windows_NT_Server_Vers... "Disc contains code to run on Windows NT-compatible x86, Pentium, MIPS, R4x00, Alpha, PowerPC and Pentium Pro systems"
- pnako 6y ago
  Way before that they had ARM-based Pocket PCs running Windows CE (or Windows Mobile).
- jupp0r 6y ago
  Windows itself has never been the problem, but the Software that’s running on it.
VWWHFSfQ 6y ago
It will be very difficult until Windows is POSIX-compatible. Whatever that means, I don't know. But it can't just be the Windows Subsystem for Linux. The whole OS needs to have POSIX compatibilities.
- wongarsu 6y ago
  Windows NT used to have a POSIX subsystem [1] that applications could use instead of the Win32 subsystem. So the Windows NT kernel is designed with the option of POSIX compatibility. Arguably the Subsystem for Linux is the current successor of the POSIX subsystem, providing POSIX compatible access to the kernel along with a POSIX compatible shell and UNIX commands. Obviously the Win32 subsystem isn't POSIX compatible, but I'm not sure why we would want that. 1: https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
  - jacobush 6y ago
    That subsystem was just so they could tick off the “POSIX” box for Department of Defence.
    - pjmlp 6y ago
      That was one of many, then came SFU, followed by SUA. GNU/Linux users should be happy that old Microsoft didn't bother to do that much with POSIX subsystem. Had they actually invested into keeping it up to date, and many of us on PC land would never bothered with FOSS UNIX clones.
      - jacobush 6y ago
        Yeah, that may be true, but on the other hand, had they made it useable, portabilith with other Unix would have been a simpler option. Simpler than Win32 + Unix portability in any case. Or in some cases, software would have been ported to Win32 at all.
        6y ago
GordonS 6y ago
Windows is my daily driver, and I spend most of my time at work these days building dotnet core applications for Linux on both x64 and ARM. It's a great dev experience Seeing what was coming with cloud and making .NET cross-platform was very well timed.
DeathArrow 6y ago
Microsoft tried countless times to move to Arm. The most recent efforts are with their Surface Pro X, their SQ1 CPU and pushing Qualcomm to release Snapdragon 8cx CPU for ARM laptops. But most software development companies didn't care enough to recompile their software for Arm and running X86 software in emulation is not exactly a good experience.

Koshkin 6y ago

> brilliantly avoided mixing up C++/COM I remember VB6 was also exceptionally good at this.

KeBugCheckEx 6y ago
Actually a lot in COM was made to work on vb. COM string type is BSTR which stands for Basic STRing.
pjmlp 6y ago
COM is both an evolution of VBX and a subset of OLE 2.0. .NET was going to be what UWP is now, an evolution of COM, but then Java happened, and they went with something similar instead. There are some references to how this all happened in the story of F# evolution, given that Don Syme was part of the team since the early days.

peatmoss 6y ago

How can we bring this to Linux/BSD? Specifically the GUI layer? I’ve lamented that Linux desktop world has been fragmented and alien as compared to other major environments. I used to think that things would have been better if we had chased GNUStep and source compatibility with macOS. I feel like the non-GUI userland in Linux is best in class and is effectively a given for any server deployment. But all the developers I know cobble together a mediocre Linux-like environment on macOS so they can have a first-class desktop environment and an okay development environment. On the other hand I read about people using Windows as development environment by using WSL. I feel like Linux will never organically gain critical mass for a desktop environment—substantial source compatibility with some major platform seems like the way to go. How are the Windows APIs vs the Cocoa APIs these days? Assuming source compatibility could help boost desktop Linux’s fortunes, is Windows or Cocoa a better target? Does consideration of iOS change the calculus?

pjmlp 6y ago
It is already available, it is called GObject, KParts, D-Bus. If the community has embraced a proper desktop eco-system around them, like the component vendors on other platforms, they aren't going to start now. I surely don't see job offers for Linux/BSD GUI toolkits as I see for Apple, Microsoft and Google ones. WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do the same. For traditional Windows developers it doesn't really matter. PowerShell + Windows Terminal is where the action is.
- fluffything 6y ago
  > WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do the same. Do you know many people that used to do this with macOS and are now using Windows ? Like, oh boy, I tried, but after 4 months I ended up back with macOS.
  - sfifs 6y ago
    In my experience, one of the the problems is that Macs are hilariously underpowered for many modern dev and analytics use cases. So the workaround is to work off remote machines/clusters over web interfaces/SSH but for many development use cases that's just slow and clunky - the have merit more in productionising. The series of hardware clusterfucks on Mac haven't helped ether. So I've seen Mac users who work in these areas get sick of the issues and limitations and switch to Win 10 + sometimes WSL. The people remaining with Macs are executive suite (who go for iPad pros) and account execs who do sales where it looks cool to go pull out a Mac. However even there people are increasingly looking dumb when they want to present something and go on 5 min dongle troubleshooting hunt because Mac killed HDMI and VGA ports and start their presentation appearing incompetent. Sometimes over web screen shares, only the desktop shows and not the applications. By refusing to focus on hardware/software quality and power users, Apple has lost the game on high end.

masklinn 6y ago

> except maybe for the winrt::import that looks like Go? It looks to be a pretty extensive codegen hook, generating bindings to the referenced runtime components on the fly based on the module metadata it finds on the system. Apparently the C++ version uses IDL and an explicit codegen step instead: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt#windows-runtime-component-cwinrt https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...

steveklabnik 6y ago
It's a really intriguing approach; most use "build.rs" to do codegen.
- masklinn 6y ago
  Seems sensible though, the build.rs solution would require every project using rust/winrt to have a build.rs and code to load & codegen the modules (probably copy/pasted), so it'd be a lot more work for users of rust/winrt, though I guess it'd be less magic.
  - steveklabnik 6y ago
    Oh yeah, I agree. I’m really interested to see if this approach would work better than build.rs for some other projects too.
    - ratmice 6y ago
      Bah... This seems like exactly the kind of thing that makes dependency tracking, and sandboxing compilation harder.
      - steveklabnik 6y ago
        Why? I'm not an expert here, but it seems basically the same to me.
    - 6y ago