Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Core 3.0 Concludes the .NET Framework API Porting Project

github.com

Post reply on HN
Print view View original

241–250 of 317 posts

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#241

Post by Faark »

x3haloed wrote: post #190
gnud wrote: post #41

Earlier quoted context omitted.

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.

> 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…

> 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.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#242

Post by snagglegaggle »

pjmlp wrote: post #226
snagglegaggle wrote: post #220

Earlier quoted context omitted.

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 cl…

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.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#243

Post by rkagerer »

gnud wrote: post #41
jug wrote: post #3

.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 in…

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.

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.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#244

Post by Faark »

moron4hire wrote: post #165
goto11 wrote: post #108

Earlier quoted context omitted.

Structural typing is different from dynamic typing. C# supports structural typing in the form of tuples and anonymous types. But you can't return an anonymous type from a method. This is a significant limitation. As for "free" functions: C# already recognizes the usefulness of this in the "using static" directive. This is useful for a lot more than "hello world".

You can't return an anonymous type, but the syntactic difference between an anon type and a tuple is two characters: parens instead of curly braces.

And the little "new" in front of it. I actually preferred the curly braces version and would have loved for them improve it instead of creating a replacement.

And well, I'd expect them to get it right eventually. It is at least their third evolution of that feature... there was a System.Tuple as well. Wonder if they ever come out and officially deprecate their earlier attempts.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#245

Post by WorldMaker »

fauigerzigerk wrote: post #59
pjmlp wrote: post #12

Earlier quoted context omitted.

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…

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.

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.)

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#246

Post by youdontknowtho »

fauigerzigerk wrote: post #186
pjmlp wrote: post #144

Earlier quoted context omitted.

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.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#247

Post by Const-me »

fauigerzigerk wrote: post #236
Const-me wrote: post #230

Earlier quoted context omitted.

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 ot…

>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 s…

> 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.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#248

Post by Scarbutt »

surban wrote: post #29
jeswin wrote: post #7

Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…

> My wishlist for C# is short: [...] F# provides all of them, is shipped with .Net Core 3.0 and also works great on Linux.

F# is a nightmare you want to use asp.net core.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#249

Post by numo16 »

merb wrote: post #149
UglyToad wrote: post #146

Earlier quoted context omitted.

I'm currently building an open source (not copyleft) PDF library for.NET standard [0] and I'd be interested to hear more what you need on the document generation side. The current generation API for my library is extremely limited because I've never needed one but you are the perfect market research participant. It's an API I'm actively looking to improve. PDF/A compliance is probably quite a way off though. [0]: htt…

wow that looks really nice. actually we mostly do html to pdf, but maybe I can look into your project and try to add it (if there is a nice html/dom library like java has with jsoup). basically we don't need a lot, mostly switch fonts/text sizes/images (generated barcodes, logos) and of course pdf/a-3(a/b/u) for invoice. so apis that translate the html into the layouting of pdf is the bigger problem.

For html/dom parsing, I would recommend looking at either AngleSharp[0] or HtmlAgilityPack[1], as they tend to be the most popular in the community.

[0]: https://github.com/AngleSharp/AngleSharp [1]: https://html-agility-pack.net/

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#250

Post by samus »

gnud wrote: post #41
jug wrote: post #3

.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 in…

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.

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