wil VS Windows Terminal

Even then, MFC and C++/CX were the only productive ways to use it from Microsoft SDKs.

.NET isn't as convenient as VB 6 was, fully embracing COM as the VBX replacement model, technically introduced in VB5, but still some stuff was lacking.

Then there is Delphi and C++ Builder.

It beat me that having doubled down on COM since how Longhorn went down, and Windows team getting their way doing avoiding .NET to take over, they hardly managed to create nice tooling as the competition.

Editing IDL files with a Notepad like experience, manually merging generated code, and a couple of frameworks that barely go beyond yet another way to do AddRef/Release/QueryInterface and aggregation.

Meanwhile D-BUS, XPC and AIDL, provide much better dev experience.

Pity that Borland products are kind of tainted due to mismanagement decisions, otherwise maybe fixing COM dev experience would already been seriously taken by VS team.

Ah, nowadays WIL is probably the best approach when having only to consume COM.

https://github.com/microsoft/wil

Have a look at WIL for a C++ library used by Microsoft themselves, including kernel development.

I'm digging for more information and it looks like Microsoft's created a way to handle the problems I'm trying to address with this: https://github.com/Microsoft/wil/wiki/RAII-resource-wrappers

Since we are on this subject, those that need a nice C++ library to deal with COM in VC++, are better served with WIL.

Not since Vista.

https://docs.microsoft.com/en-us/cpp/build/reference/kernel-...

> Creates a binary that can be executed in the Windows kernel. The code in the current project gets compiled and linked by using a simplified set of C++ language features that are specific to code that runs in kernel mode.

And then there is WIL, https://github.com/microsoft/wil

https://community.osr.com/discussion/291326/the-new-wil-libr...

> First off, let me point out that this library is used to implement large parts of the OS. There are hundreds of developers here who use it. So unlike, uh, some other things that get tossed onto github, this project is not likely to wither and die tomorrow.

> There are, however, only a handful of kernel developers working on the library, so the kernel support has been coming along much slower. I'd like to expand the existing kernel features in depth ....

> Plus C++ standard library can't be used anyway and auto pointers aren't really that much of a concern at the kernel level

https://github.com/microsoft/wil

"Ah, but that isn't used on the Windows kernel" would be the expected reply, well

https://community.osr.com/discussion/291326/the-new-wil-libr...

"Microsoft's toolchain does not ship a copy of the STL that works in kernel mode. Partly this is because the kernel's CRT doesn't support C++ exceptions. (And partly this is because I/O is wildly different in kernel, so you'd have to rewrite the implementation of all the I/O libraries.)

But for kernel developers, wil ships a subset of an STL implementation. To avoid conflicting with the real STL, it's available under the wistd namespace. The rule of thumb is that wistd::foo is a drop-in replacement for std::foo."

Windows is a mix of legacy C code, which started to be migrated into C++ around the Vista time (hence /kernel in VC++) and .NET/COM (WinRT is basically COM with some extras).

Modern kernel code makes use of WIL.

https://github.com/microsoft/wil

> convince management of the value

This presupposes that such convincing is even possible. Many, many companies have leadership that are simply terrible at identifying value. If you've never been part of a majority of developers advocating for, if not outright begging for, some huge ROI initiative to get the green light, you are very fortunate.

There are great counterexamples, like Valve, which is known for giving developers an extreme degree of autonomy, and they benefit greatly from that approach. For each Valve, though, there are dozens of companies that manage to succeed despite themselves.

Take Microsoft, for example. One tiny, yet representative, example: the way the Windows Terminal team handled a suggestion from Casey Muratori to take their software from abysmally slow to lightning fast:

https://github.com/microsoft/terminal/issues/10362

A quote from one of the Terminal developers, dismissing the suggestion:

> I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively…

Just how difficult was such an endeavor in actuality? Well, given that Casey implemented his own terminal emulator from scratch and incorporated the functionality he was proposing in a mere weekend... not a whole lot. Relatively minor effort for a huge return on investment. It took Casey explaining the concepts, then providing a working proof of concept, and finally a bunch of backlash online towards the Terminal team to get them to do the right thing for themselves and their users.

At this point ConHost.exe is open source [0] so it is maybe not a stretch to expect Microsoft to open source CMD.EXE at some point.

Though with PowerShell being cross-platform and already open source, I personally don't think there's enough to gain in some sort of better open source CMD.EXE fork. I'd be interested in being proved wrong on that, but I'm also happy enough with PowerShell these days I'm not in a hurry to return to CMD.EXE.

[0] https://github.com/microsoft/terminal/tree/main/src/host

"Users of Linux and macOS may well be familiar with the sudo command, used regularly in the terminal, and it looks like Windows may finally be getting its own version."

More Linux tools are coming to Windows, especially Windows Server because the tools are good and they make it easier to administer a Windows Server.

They are looking at adding a default TUI text editor (https://github.com/microsoft/terminal/discussions/16440) and now they are adding sudo.

I would not be surprised if systemd or something like it gets ported or reinvented for Windows simply because it makes managing services so nice.

GitHub

>We are allowed to view and consume it, to be influenced by it, and under many circumstances even outright copy it.

People keep saying this but it's actually much more complicated, and in many cases you can't view copyrighted content.

An example, MicroSoft employees are not permitted to view or learn from an open source (GPL-2) terminal emulator:

https://github.com/microsoft/terminal/issues/10462#issuecomm...

Another example is proprietary software that may have it's source available, either intentionally or not. If you view this and then work on something related to it, like WINE for example, you are definitely at risk of being successfully sued.

If you worked at MicroSoft and worked on Windows, you would not be able to participate in WINE development at all without violating copyright.

If you viewed leaked Windows source code you also would not be able to participate in WINE development.

An interesting question that I have, is whether training on proprietary, non-trade-secret sources would be allowed. Something like unreal engine, where you can view the source but it's still proprietary.

Windows Terminal is pretty good and a new terminal emulator written in the last few years. No smooth scrolling, here's the GitHub issue requesting it: https://github.com/microsoft/terminal/issues/1400

Assume its related to this:

https://github.com/microsoft/terminal/issues/10362

It's nothing serious just microsoft engineers writing slow as shit code and reacting poorly to someone trying to help.

"There are plenty of offline scenarios where this would be incredibly useful. For disconnected environments, etc. There are some environments that will never connect to winget."

Source: https://github.com/microsoft/terminal/discussions/16440#disc...