Common controls, especially shell controls, come in different versions of comctl32 etc. and have been versioned and dynamically selected in the basis of things like application manifests for backward compatibility reasons for a long time.
API structures have different sizes so code usually needs to change to support later versions.
Seriously though, why were the fonts hard-coded to use ms sans serif instead of the OS default font (eg Segoe UI last time I checked?)
I may hate their practices but their dev tools have always been absolutely top-notch within their (locked down) garden. No company has ever come anywhere close to emulating that, closed garden or not.
Seriously I have tremendous respect for anybody who works on a project that massive, I just meant it in the sense of "there are two kinds of languages, the kind people complain about and the kind nobody uses".
Of course there were a lot of jagged edges in winforms (like the font thing) - I never used a GUI framework that didn't have any of those.
Lots of stories, here's some quickies:
- Windows Forms was originally WFC from the Visual J++ project. Anders Hejlsberg was the architect as one of his first MS roles, working with him was a huge impact on my career.
- The Winforms team was, I think the first team to ever use C#, which was called COOL (C-Like Obj Oriented Language). Before then we were using a Java-like language that ran on the CLR
- The .NET Framework originated as a mash-up of the Winforms and ASP.NET teams, who were busy building frameworks separately for a while.
- The .NET project was a boiled ocean - everything was new from the runtime (CLR) to the tool (VS.NET), and two languages (C#, VB.NET). We didn't have a working debugger until late in the cycle, everything was always on the floor. This might be an anti pattern.
- I don't remember exactly what the story was with the font...20 years!... but my guess would be that it had to do with dealing with different versions of Windows and which fonts were installed.
The PropertyGrid was quite lovely. I dimly remember being envious of Visual Studio having that cool no-frills edit-my-object widget and it wasn't initially available as part of the forms lib, but iirc there was some trick you could do to use it... I tried once but gave up on the learning curve because it was so designed for object properties and I wanted to use it to manipulate a datarow. I assume it got a more line-of-business-developer version in its later incarnations.
WPF just came at the wrong time, as mobile was about to ascend and added complexity (which I'll admit can definitely add to correctness). Given hindsight, they should've just extended WinForms in some way. Leaving more complex needs than whatever that extension entailed to the Win32 API. UWP is fine and would be the greenfield target, but being Windows 10-only makes it a nonstarter at any enterprise I've worked at. So it's WPF/UWP that are essentially dead to me. Once Windows 7 is completely abandoned, I'll change my tune and stop promoting WinForms and go with UWP. But not today.
I'm all about building out on WinForms, or while not a UI framework, Blazor. The latter of which is part of an application/UI rewrite that we're looking to do for a WinForms app that I maintain, once it hits 1.0.
WinForms does the job and it allows me to almost entirely focus on the business logic.
WPF was designed to merge the best of client with what was happening on the web at that time. Data binding, declarative layout, model-view separation, these are all much better BUT you're also left dealing with styling, transitions, other stuff. WPF is clearly more powerful (I also worked on Silverlight fwiw), but takes more skill to operate.
We were targeting the VB6 user who was creating LOB apps at a big enterprise and wanted to get things done and move on.
Instead, I'd rather have seen a path that led to just WinForms and UWP today. If you read the link that I provided, the author feels the same. WPF is the most pointless of all three. If you want XAML, there is UWP and it's more useful, and has a better future. It's hard to imagine much of a future at times for even UWP with Electron's popularity and HTML/CSS web interfaces.
It's clear that Microsoft is gearing up for massive Electron optimization with their adoption of Chromium, so that's going to just accelerate as those apps run better and use less battery while doing it.
For me, native GUI might just die with WinForms. I'd hate to see it go, it's always going to remain ideal for internal tools.
WinForms is the original and best... and I think the only widget kit from it's generation still around and maintained
The part that you are referencing was part of the CLR (nee COM+) organization. This native compilation didn't happen for a couple of reasons:
1. Serviceability - the idea was that we wanted to be able to roll out new assemblies with fixes (remember this was in the "oh shit" phase of security awareness at MS)
2. Optimizations - there was an idea that you wanted different JIT to happen based on end machine architecture, server vs client, etc.
3. Size - at this point the size of the resulting binaries (for distribution) was still a concern. At that point it seemed better to have fat frameworks updated by Windows Update, and smaller apps that depended on that.
Many of these reasons seems less compelling now. MS was often a bubble in those days. I left in 2012 but it seems better now and it shows in their products.
I was there during the early days from the customer side, my employer was one of the selected MSFT Partners to get access to the pre-betas as a way to provide early feedback and be in the position to announce .NET based products on .NET 1.0 launch day.
Still remember all the .NET early docs full of red paragraphs, WIP sections or big warnings that some areas were still in the process of being fully defined and subject to change.
I always love to hear these stories.
Uncaught abort(20) at Error
at jsStackTrace (https://webassembly.z19.web.core.windows.net/Calculator/mono.js:1063:12)
at stackTrace (https://webassembly.z19.web.core.windows.net/Calculator/mono.js:1077:11)
at abort (https://webassembly.z19.web.core.windows.net/Calculator/mono.js:18097:43)
at nullFunc_ii (https://webassembly.z19.web.core.windows.net/Calculator/mono.js:14694:2)
at b20 (wasm-function:31)
at emterpret (wasm-function:12351)
at _do_icall (wasm-function:63)
at emterpret (wasm-function:7917)
at _interp_exec_method_full (wasm-function:65)
at emterpret (wasm-function:7129)
if (opr2 != 0)
result = (opr1 / opr2).ToString();
MessageBox.Show("Can't divide by zero");
Edit: I'm wrong, it's a WasmWinforms bug.
dl_mapping_symbol MessageBox - proc name MessageBox not matched
var TOTAL_MEMORY = Module["TOTAL_MEMORY"] || 1258291200;
More seriously, looking forward to when CLR can compile down to web assembly directly rather than requiring a large runtime. Baby steps.
Yes I know it isn't the same XAML.
Solutions like this have already existed and still exist today. ASP.NET Webforms was basically the same attempt as this but with HTML5 base controls.
Running .NET on the browser was a great idea on paper for cross-platform application , but seing how much time it takes to load the entire .NET framework it’s just isn’t a suitable solutions for production.
Blazor is the official Microsoft project that uses a small .NET runtime with Razor components and is already smaller and faster than many JS bundles without any optimizations.
On a positive note, as I watch the assemblies load, Angular sites with 50k or so npm packages doesn't seem so heavy :-)
Am I misunderstanding how web assembly works?
It doesn't show the source file because the browser is not actually aware of where the js on the page got the wasm its running from. From the browser's perspective it just fetched an opaque file and then separately got told to run some wasm.
You can see the actual source file for the wasm for one of the demos here, it still shows up in the network tab (but for example if the js on the page generated the wasm then it wouldn't). https://webassembly.z19.web.core.windows.net/mono.wasm
In any case, it's pretty insane what they do now but I sort of fail to see how W(eb) assembly is different from let's say a Java applet?
It is not native code is it?
It’s starting to feel quite left behind at this point.
Sooo, unity webgl may not work on iOS but that doesn’t mean wasm itself doesn’t work.
Edit: Trying it in Firefox desktop it fails too, so obviously this is not really fully cross-browser compatible yet.
 RangeError: bad Memory initial size
Par for the course in the "modern Web"