Hacker News Reader

Comment by jug | Hacker News Reader

.NET Core 3.0 was major achievement for Microsoft and I like the air surrounding the project and some around it like Visual Studio Code and Windows Subsystem for Linux.

The teams working for Windows development are overall on a roll these days and it's both sad and a little mysterious how Windows 10 is still struggling with QA issues, decisions like dismantling their internal testing teams, dual control panels and inconsistent design.

I've heard Windows devs speaking up off the record that it is hell to work on with so much boilerplate and ceremony both in practice and politics and with few understanding all the ins and outs of building for their Windows 10 desktop, many restorting to copy & pasting because "it's just supposed to be like that". That makes it a little easier to understand why their aforementioned old control panel is still around even after five years of work on a new one.

I wish they could somehow restructure and streamline and come back to also be able to share the excitement like the .NET Core team are doing right now. Maybe if Windows 10X is a success? Maybe Windows is indeed just getting too big for its own good and the Win32 apps are best just put into one fat virtualized environment for backwards compatibility, like in that upcoming evolution of Windows.

Then write the Windows user land in .NET Core.

View on HN

I love it every time I get the 'old' control panel. It means I know where the switches are, and more importantly, what they do.

The new UIs change with every minor update. Layout, labels and semantics. It's truly horrible. Please don't encourage Microsoft to mess it up even more.

Yes, if things keep changing around or is hard to find, that's annoying but I see this as a separate problem from a bad pace and inconsistency. Nothing here in particular hinders good and well researched design.

I could find stuff in the old panel without knowing where it is. I can't in the new one. Either because the options are missing entirely or because they're too well hidden.

My biggest gripe is not being able to directly open the old settings... Always having to open "control panel" and then clicking on the correct category gets old fast, but is nonetheless more effective than fruitlessly searching in the new panels until I give up.

Not to mention that the 'old' control panel has a lot more options!

>It means I know where the switches are, and more importantly, what they do

Or even more importantly than that, that they even exist in there somewhere.

My goodness.

Recently I went to play a game on my laptop, something i don't normally do. I'm not even normally a windows user.

It has this 'feature' where if a key is pressed then it disables all mouse clicks for X number of seconds. This is to prevent a forearm from tap to clicking on the touchpad while typing. Absolutely makes sense.

Only... I had a mouse plugged in. It disabled a physical USB mouse from clicking after a keypress. Even after disabling the touchpad entirely it continued this behaviour.

After some Googling there should have been a switch in the modern Windows 10 style mouse config. But it wasn't there.

More Googling, "go edit this registry key" but i didn't have that registry key.

More Googling, the registry key depends on your touchpad driver.

More Googling finally found a way to disable it globally with regedit.

#1 Why was the switch not available in the mouse settings #2 Why was it applied to a usb mouse #3 Why did the registry key differ depending on mousepad driver.

Just a nightmare.

This one is mostly the touchpad driver being poorly written and or outdated. Let me guess, Synaptics touchpad?

For some inexplicable reason their newer touchpads (in newer laptops) support the Settings configuration, whereas their older ones (in older laptops) only work via the Mouse Control Panel applet (and sometimes not even then).

I've also had their touchpad driver cause keyboard input latency (it tries to hook hotkeys) with uninstalling it entirely and having no touchpad being the only solution. Their stuff is just bad, and they should feel bad about it.

I doubt they do feel bad as they have a seeming monopoly on Windows laptop touchpads.

I've got a Macbook Pro and it doesn't seem to have or need this feature in the first place.

It does have an analogous feature, the MBP's trackpad is huge and you probably touch it by accident all the time.

It's just that Apple's system tries to separate deliberate touches from accidental ones, rather than disabling the trackpad input completely.

You used to be able to turn this on and off (it was called "Ignore accidental trackpad input" in the trackpad preference pane) but now it's an always on feature. The trackpad has extended so far into the palm rests that it would be very difficult to use without it, and the feature works well enough that you don't even realize it's happening.

https://support.apple.com/en-us/HT201822

Yes, I touch the pad by accident all the time. But why is Apple so good at detecting which touches are accidental, while so many other manufacturers are not?

On Linux this works similarly. ~5 years ago my old laptops did the 'disable touchpad when typing' thing, now with libinput the touchpad has excellent and completely invisible (to the user) anti-false-touch functionality.

Apple has invested the time to make great trackpad drivers. People have invested time to make libinput a great driver for Linux (in this regard - it does lack customization possible in older drivers).

On Windows the manufacturers don't care. IIRC MS is doing a thing where manufacturers can add some property to their touchpad HW/drivers which tells Windows to handle the touchpad entirely on its own, and the result has been that touchpads have been improving significantly over the last few years since MS is investing time in making good drivers. But that depends on your specific touchpad allowing Windows to do its magic, instead of using crappy OEM drivers.

That is fantastic news about Linux. I bought a System76 four or five years ago and the touchpad was terrible. It wasn't just false touches; it was really hard to accurately click on something, the pointer kept making little jumps. Would you say that's better too?

If touchpads are good now, then I might go dedicated Linux again when it's time to upgrade from my aging MBP.

Try making an Ubuntu/Fedora USB and booting from it once on your MBP, that should let you see what it's like. I had to explicitly disable the 'disable touchpad while typing' libinput setting but aside from that everything works great out of the box.

Cool, thanks!

It may work quite often without me knowing, but ever since I got a 2017 Mac I have multiple events per day where my typing ends up in a random location due to phantom clicks. Perhaps I should disable tap to click, even though I really dislike clicking via the force push.

Not only that but the new interface is becoming just as complex as the old. By the time they have finished they will be back where they started.

Nah, it's pretty simple these days and people who love scripting can use powershell for everything

Nah, it’s getting just as complex as the old interface, there is nobody with the ability to say no, this is too much.

I’m a big fan of PowerShell, I have embedded it in two products. However it’s not a good justification for a poor user interface.

And also items from the old control panel don't appear any more when you search in the start menu.

Which would be ok if they had been replaced by an equivalent in the new menu. But they have not. So what is the point in hiding them?

Let me have their pretty UI. If you want to geek out, there's Powershell.

Powershell is shit for discovery & not useful at all for the majority of Windows consumers i.e regular users. You shouldn't need to learn powershell to switch your audio output

See a few comments up this very comment chain. They’re hidden because they look dated, regardless of their usability

They're removing the pre-Windows 10 Control Panel items with a new Settings interface. The problem is that it's far worse:-

Tasks such as changing network adaptors setting, or sound settings. I regularly switch between three different audio devices on my desktop PC, and doing simple tasks such as toggling volume levelling isn't in the new interface and digging into the old is becoming harder and harder to find, with more clicks for every revision. Just yesterday I went to add a firewall rule, and that was hard to find. I'm an MCSE, so you would think I could change a firewall setting!

It definitely doesn't feel like an improvement, it feels like they're forcing an abstraction. Plus they've recently removed the Control Panel when you right-click the Start menu. That was about the only 'Safe Space' left.

I feel for anyone who has to support Windows 10. They're definitely not listening to the users. This is the FisherPrice interface all over again, but there's no stopping it this time around.

> It means I know where the switches are, and more importantly, what they do

Does that mean you would never be comfortable with with a complete UI overhaul?

> The new UIs change with every minor update

I completely agree that this is a problem. And this part of my biggest issue with Windows 10. They're constantly reworking the new UI for what seems like micro-optimizations, but they're mostly ignoring the old UI. Not only is it a headache for users to keep up with new paradigms every 6 months, but there continues to be two areas in Windows to control system settings, one of which is hidden pretty well, and the location of settings between the two is continually changing. It's a nightmare.

.NET Core, on the other hand, is pure gold. It's fast, it runs everywhere, it's well document, and it's a joy to work with.

Which leads us to Visual Studio, which is becoming like Windows. Constant tweak updates that break things. I stopped installing '.0' releases, beacsue they're consistently broken.

> Does that mean you would never be comfortable with with a complete UI overhaul?

I'd like for the old interface to be still around, so I can click though the nav layers like I always have. At the end, instead of the information / setting I'm looking for, I'd be fine with info on how now to find that info/setting. This "tutorial" should obviously be kept up to date on later UI changes. It also requires the info/setting to still be available... so no dumbing-down please.

same here. I still prefer the old control panel. They hid everything behind "usability". I'm sure for a lot of people it's more usable, but for me it's just more painful.

I call it the Windows control fractal. Each new version of Windows requires clicking through a totally new UI layer to get to the previous version's control panel. Finally you arrive at the Windows 95 settings program you were trying to get to in the first place.

Agreed. Most of my time trying to adjust settings in Windows 10 is spent trying to locate the 'old' control panel dialogs. What's sad is that all their attempts at redesigns and tweaks have not resulted in something I want to use more.

Funny, I always thought the same things about the control panel of various other window environments like Gnome and KDE.

I can sum up the situation with two sentences:

I hate writing Win32 apps, but I love using them. I love writing .NET apps but I hate using them.

The problem with Win32 apps is that although they look ugly, in general they're blazing fast and work basically everywhere. The problem with .NET apps is although they're aesthetically pleasing, they require the relevant version of the framework to be installed. I remember fighting with installing a .NET-based driver installer that insisted on installing an ancient version of .NET that Windows wouldn't allow to install. Win32 support is still universal.

Core apps can be deployed standalone

With .NET Core 3, you can deploy them standalone, and performance is much improved. So you might have a happy middle ground available now.

And when I say performance is improved, there are two fronts to that. First, the compiler/jit are just better now, core library functions are sped up a ton, so just running ported old .NET Framework code will be a lot faster. But also, C# has added new features in recent years that give you further control over memory usage/layout, and now even SIMD Intrinsics, so the performance ceiling is much higher if you want to optimize your own code.

Piggy backing on this a bit..

You can now publish a .net core 3.0 app that is: 1- Ready to Run: Part AOT compiled app for the platform. 2- Trimmed: Tree shaken down to only necessary bits from the framework. 3- Single File: Self contained app.

This combination of features provides a really decent balance between size, performance and distribution.

This oldie seems relevant: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c...

1 year to build Windows Vista's new shutdown menu, with a total of 43 people somehow involved in its design. If this is how Windows developers still have to work, it's no wonder.

That said, I would readily believe that the roots of this story have more to do with the complexity of modern OSes than any particulars of Microsoft culture. In terms of software quality, OS X peaked about 15 years ago, and has been steadily getting flakier ever since. And the Linux community has been struggling for virtually its entire existence, without success, to deliver a well-polished desktop experience.

ChromeOS? Is that a success? Lots of concessions there I guess though.

Windows userland is being rewritten in COM since Vista, as the Windows team picked up the Longhorn ideas and used them in COM after winning the WinDev vs DevTools politics, I doubt they will change route.

The best we can hope for is that with the new AOT/JIT infrastructure, it gets more equal footing with C++/WinRT in platform APIs.

After all, it has won the UI, MFC is legacy and XAML/C++ doesn't have much uptake as most companies rather do C++/COM and then consume them from .NET for the UI part.

One of the key problems of our time (besides antibiotics resistance, climate change, lack of affordable housing, poverty, rise of nationalism and totalitarian ideologies, mass surveillance, etc) seems to be the impossibility of reliably generating reference counted code from code written for a tracing GC.

Nah, that key problem will eventually be sorted out with a couple of generational changes.

Said someone in the 1960s ;)

I'm serious (even if it may not sound like it). COM is a fantastic platform, because it provides simple and efficient interoperability between language runtimes.

But code written for tracing GCs cannot be automatically transformed into COM's (or any) reference counting scheme. And that's why we have this endless tug of war between those who want to build on top of COM versus those who want to build on top of .NET.

It's not just a Microsoft problem either. Our industry has been wasting a ton of resources on duplicating everything for a bunch of different languages/runtimes and it's all either because of GC incompatibility or license incompatibility.

It's not a minor problem even if there are more important problems in the grand scheme of things is what I'm saying.

May be I don't understand something, but how does it differ from e.g. operating file handles? For example in Java you're supposed to use try-finally to close file handle. You should do the same with reference-counted objects, just manage their lifetime manually. And finalizers will close it for you if you forgot to do that (that should be considered as a bug, but not very serious).

It doesn't differ from that, but in languages that assume the presence of a tracing GC, that pattern is only used for resources other than memory.

And therefore you can't (as far as I know anyway) compile arbitrary C#/Java/JavaScript libraries down to reference counted COM in order to make those libraries available to C++ or Rust code.

You can also use that pattern for memory management in .NET.

For example stack allocations and unmanaged memory handles.

.NET COM interop take care of exposing .NET classes to other COM aware languages.

https://docs.microsoft.com/en-us/dotnet/standard/native-inte...

You can, but in order to translate arbitrary .NET code into reference counted COM you would need a guarantee that _all_ code is written like that or that you can statically infer the correct reference counting for _all_ code that isn't written like that.

I haven't seen the reluctance to use the runtime in interop scenarios. Is this just a personal interest or do you have a particular use case? I'm genuinely interested.

This debate is about Microsoft's decision some 14 years ago to build Windows userland components on top of C++ COM technology instead of .NET as some within Microsoft had wanted.

Those inside Microsoft who didn't want to force everyone to use a rather heavyweight runtime including a tracing GC won the debate. It would have affected almost everyone, not just those with use cases that can tolerate the significant additional resource usage.

I merely made the observation that the difficulty to infer correct reference counting information from C#/Java code is what caused this rift and a lot of unproductive duplicated effort in our industry.

I see what you mean. Good point. Cheers.

Offtopic, but I think that Rust memory model makes a perfect consumer of COM services :) May be it'll be integrated to other languages as an additional type system.

I’ve been writing C++ COM objects for use in .NET for years now. Some are for performance-critical parts, like manually vectorized SIMD code. Another use case is interop heavy code, using Direct3D, media foundation, Eigen, other C and C++ libraries.

It works even on Linux https://github.com/Const-me/ComLightInterop I also have these parts, especially about the interop. Libraries like drm, kms, gles, udev, and many other kernel APIs are only usable from C or C++.

Had very few issues with IUnknown-based interop. On Linux, my interop library retains .NET objects with GCHandle while they are referenced by C++ code. On Windows, it’s done automatically by the runtime. C++ implemented objects are automatically retained on both OSes.

What exactly do you think is a hard problem about such interop? Leaks due to ref.count cycles are possible, but I’m not sure it’s such a huge deal. There’re many good reasons to keep interop API surface small, with obvious “who owns what” relations.

>What exactly do you think is a hard problem about such interop?

The problem is that .NET libraries cannot be used from C++ or Rust without depending on the entire .NET runtime, including its tracing GC, which is obviously extremely undesirable.

And that is probably why Microsoft dropped their plans to write Windows userland components in .NET and decided to write them in C++ instead (exposing COM interfaces).

As I see it, the key theoretical issue is that neither CIL nor arbitrary code written in languages like C#, Java, JavaScript or Python contains enough static information to generate purely reference counted code.

You're seeing the same on Unix. All truly reusable code is written in languages that don't require a tracing GC. Everything that is written in other languages is duplicated for each language/runtime environment.

> cannot be used from C++ or Rust without depending on the entire .NET runtime

You can compile .NET into native code if you want: MS .net native, Unity’s IL2CPP, etc. These aren’t some research projects, every Unity3D game shipped on iOS compiles with IL2CPP, most windows store apps are built with .net native. The GC probably still included in the output binary somewhere, but it does much less work than usually.

> which is obviously extremely undesirable

Depends on use case. You wouldn’t want to bring the runtime for a small dependency, but for a large and complex one, like PDF writer or embedded web server, it can be OK. The 2.2 runtime binaries are 25-28MB depending on the platform, not a huge deal. These days, people bring 150MB+ Electron dependency just to render a few strings and colored rectangles :-)

> the key theoretical issue is that neither CIL nor arbitrary code written in languages like C#, Java, JavaScript or Python contains enough static information to generate purely reference counted code.

C# and Java and strongly typed, have a lot of static information. I think the main reason why it’s impossible to reliably recompile these languages into non-gc code — circular references.

>C# and Java and strongly typed, have a lot of static information.

They may have a lot of information, but they don't have the static information required to generate reference counted COM. It's information about the lifetimes and ownership of objects.

>I think the main reason why it’s impossible to reliably recompile these languages into non-gc code — circular references.

Exactly. The information to resolve those is missing.

>Depends on use case.

This was a debate about Microsoft's decision not to build Windows userland on top of .NET after all. So it would have affected all use cases of all Windows developers.

But why should reference counting code be the "default" over a tracing GC in the first place? If the "problem" is embedding tracing GC inside of reference counted worlds, but tracing GC itself has little to no problem embedding reference counted worlds, why not invert the stack?

Lisp machines in the 60s were doing tracing GC in hardware. It's not like we don't have the technology to move tracing GCs further down the stack. Sure, reference counting is "simpler", but it's also easier to do wrong. It's harder to get tracing GC wrong. (Sure, we can debate for days if its harder to get tracing GC performant, but it can and has been done, including as mentioned directly in hardware.)

Hey for people that don’t follow windows internals and politics closely, what did the devTools champion ? What are the longhorn ideas that are getting into windows ?

Long story short, that you kind have to assemble from blog posts, forum comments, between the lines articles and so on.

Longhorn was to be built on top of .NET and there were lots of issues, regarding performance, stability and what not.

Apparently it was more a thing of WinDev (owner of Windows and C++) and DevTools (owner of VS and .NET) each pulling to their side instead of collaborating.

As proven later by Singularity and Midori it was an achievable goal, when everyone on the team believes on the end goal.

Instead Sinofsky team took over, several ideas were dropped, others were reborn in .NET 3.x like WPF, and Vista came to be.

Many of the .NET (Longhorn) libraries reappeared in Vista and Windows 7 as COM libraries.

See Project Hilo sample, https://blogs.msdn.microsoft.com/jasonz/2010/06/06/project-h...

Later WinRT was born, which is an improvement over COM, using IInspectable alongside IUnknown, and .NET Metadata instead of the old COM type libraries.

Curiously similar in concept to Ext-VOS, which was in the genesis of .NET, before CLR came to be.

https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net...

So WinRT (Win 8.0), eventually became UAP (Win 8.1) and now it is UWP (Win 10).

Contrary to many Windows 10 haters belive, UWP isn't tied to the store and each Windows 10 release brings more Win32 "legacy" APIs into UWP.

The next generation COM based runtime with interoperability across C++, .NET, JavaScript, Delphi and every other language capable of understanding COM projections.

Ah, and thanks to the contributions initially started by Kenny Kerr, which ended up joining the Windows team, the C++/CX language extensions got replaced by C++/WinRT a C++17 framework for UWP.

I think Sinofsky was still in Office when this was happening. He comes into the picture with Windows 8 since Microsoft wanted Windows to be as successful as Office had become. Jim Allchin (https://en.wikipedia.org/wiki/Jim_Allchin) was in charge at the time of Vista.

Office had stuck with regular the regular Windows platform and were focusing on UI and getting into a regular release rhythm under Sinofsky. People forget but Office releases used to be a real crapshoot and Microsoft needed to move to a true subscription model at some point (the original activation wasn't it.) To do this you need regular updates at least a few years apart before you can even get close to what's needed for a subscription business. Sinofsky seems to have been a real success here, but not so much in Windows.

Looking back the expectations for Vista could never meet the reality. Windows was fundamentally not ready as a product or team to deliver on any of the promises. This was not much different from Cairo (https://en.wikipedia.org/wiki/Cairo_(operating_system)) as it turned out. If the focus had been on the fundamentals like regular releases they may have been achieved some of what is promised with the right compromises. I also wouldn't discount some of the hardware changes in the period. We were getting multi-core and there was a transition to 64-bit.

Thanks for the correction regarding Sinofsky .

Undoubtedly there were multiple issues at play there.

However having been part of such "rebuilt the world" projects, I do believe politics also played an important role, as many signs that came into the outside world feel similar.

I'm not sure that is right, Sinofsky was brought in to fix windows dev after the vista fiasco, he did a good job on win 7 then went off piste with the metro ui in win 8 and that was it for him

> Windows userland is being rewritten in COM since Vista

I am not sure "rewritten" is the proper word as this implies replacement, but in reality nothing gets replaced (at least as far as the user/developer facing stuff go) and the new stuff are added on top (or alongside, depends) the existing stuff.

Also i'm not sure if the whole "exposing new stuff in COM" thing is a good idea overall. The classic Win32 GUI APIs might not provide much functionality on their own, but the plain C APIs make them both understandable by pretty much everyone and fairly easy to use by pretty much everywhere. I haven't seen much COM use on the wild since the turn of the millenium (outside of the new UWP stuff in Windows Store but really the UWP/Windows Store seems to be a different world on its own that got itself attached to the regular desktop Windows world... and even then i do not really know of anyone who uses anything from there). The most common comment i read about COM is using it to control Office but that's about it (technically DirectX APIs are also COM but in practice you do not really use much of it).

As an example, Windows had a COM API for creating ribbon-like interfaces ever since Windows 7/Vista SP2 yet pretty much every framework out there (including MFC) reimplements their own ribbon using Win32 primitives instead of using the native one.

COM is kind of like GObject and something like it has a place.

COM usage is fairly limited because using it easily requires compiler support, which only very recently was included in the Community editions of Visual Studio. You can also access COM via language bindings; most .NET code you write is COM-enabled, for example, and is accessed from non-CLR code as COM. MinGW has stuff that lets you use and generate COM classes, but it's not great. Improving it would help FOSS dev on Windows.

There are other languages that use COM also. The lead designer of Delphi was poached by Microsoft to design .NET.

Anders went to Microsoft to design J++. .NET only came up a couple of years later and as follow up on Sun's lawsuit.

Ext-VOS design document clearly refers to Java and J++.

Secondly, I have been developing for Windows since Windows 3.0 and wonder which compiler support features do you mean. Even the old express editions had the required Windows SDK tooling for COM.

No, guy I'm thinking of was hired on about the time .NET was being started. This was after Borland.

The tools may have just been for COM object generation. I found the option to generate COM code in VS2017 one day, followed up on it, and found it was the first time they had been released. The bare headers were always there but the code generators were not, at least in most current releases.

It was certainly Anders, no idea about whom you are talking about.

https://www.welcometothejungle.co/en/articles/anders-hejlsbe...

Again, I never had to enable anything on VS to generate COM components.

The old control panel can never be removed, because a significant amount of legacy software integrates itself into the old control panel and therefore wouldn't be usable if they removed it.

They also contain decades of bodges and quick fixes to get stuff to just work - working out what they need to keep and throw away must be a nightmare.

Microsoft is gradually porting what's necessary out of the Control Panel in a controlled manner. Rather than offering 1:1 functionality to existing items in the Control Panel, they're examining and rethinking everything. The new Settings App is a cross platform legacy free future.

Certain elements will likely never be ported, like Phone and Modem, but will remain forever in the Control Panel. And the Control Panel will probably be a platform specific feature of x86/AMD64 based Windows installs.

Reply on news.ycombinator.com