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

.NET Standard 2.1

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

91–100 of 124 posts

Re: .NET Standard 2.1

#91

Post by oaiey »

elorant wrote: post #77
oaiey wrote: post #58

I think they prepare already a while the shift to .NET Core as the primary .NET platform (also on Windows). - .NET Core will soon run all three UI technologies of modern Windows UWP, WinForms and WPF (.NET Core 3). - The Windows Compatability Pack for .NET Core shifted some popular .NET Framework libraries to .NET Core (some only on Windows). There are one thing, Microsoft is really bad with: Telling the world that s…

We live in a world where Cobol mainframes are still around and in use. Microsoft can not depreciate ten year old technologies when the vast majority of their clientele in this sector are enterprises.

Oh it will be supported. But it will be a dead platform like Cobol where no one wants to put new code to. With a bit of luck they will continue to support the latest C# for a while.

Re: .NET Standard 2.1

#92

Post by benaadams »

legulere wrote: post #37
stevecalifornia wrote: post #10

Suggested naming standard: - .Net API Specification - (now known as .Net Standard) - .Net Windows - (now known as .Net Framework) - .Net Cross Platform - (now known as .Net Core)

There’s already universal windows platform, which is basically windows 10 only.

UWP is built from .NET Core

Re: .NET Standard 2.1

#93

Post by oaiey »

cptskippy wrote: post #75
oaiey wrote: post #58

I think they prepare already a while the shift to .NET Core as the primary .NET platform (also on Windows). - .NET Core will soon run all three UI technologies of modern Windows UWP, WinForms and WPF (.NET Core 3). - The Windows Compatability Pack for .NET Core shifted some popular .NET Framework libraries to .NET Core (some only on Windows). There are one thing, Microsoft is really bad with: Telling the world that s…

> Microsoft is really bad with: Telling the world that something is deprecated. There is a set of technologies in the .NET Framework which have no future: AppDomains, WCF, Code Access Security, Workflow Foundation, Cardspace, ... (just to name a few). There's no reason to deprecate a mature product if there's need for it, it has sufficient test coverage, and there's low/no maintenance. There is however a risk involve…

I agree. With everything. However, a not evolving platform is a dead platform. New code should not target this platform. Even for Enterprise environments it not a joy to see the world evolve while you are stuck with a toolset a decade old. It is already now painful to see the difference in tooling between Core and Framework.

Re: .NET Standard 2.1

#94

Post by qwerty456127 »

maxxxxx wrote: post #90
qwerty456127 wrote: post #89

Earlier quoted context omitted.

> The "desktop app packs" for WPF and WinForms WinForms work quite nice on Linux with Mono. Won't they cooperate?

I think Mono Winforms is a total rewrite of the Windows Winforms. There is no shared code.

Sure it is but why not use that code to let .Net Core support WinForms on Linux the way it is going to support it on Windows?

Re: .NET Standard 2.1

#95

Post by int0x80 »

orra wrote: post #87
hoppelhase wrote: post #61

Earlier quoted context omitted.

Well, both implementations do have a strict which has the length as last member. Is there any special reason for it? Something like struct-layout optimization?

I don't think so. My guess would be that it is because a pointer to the struct can be cast to a pointer to T. I /think/ that is defined behaviour.

It is: https://port70.net/~nsz/c/c99/n1256.html#6.7.2.1p13

Re: .NET Standard 2.1

#96

Post by c-smile »

zamalek wrote: post #84
hoppelhase wrote: post #61

Earlier quoted context omitted.

Well, both implementations do have a strict which has the length as last member. Is there any special reason for it? Something like struct-layout optimization?

You can re-interpret the struct to a pointer (length would simply be truncated). Apart from that there wouldn't be any benefit: the pointer and length would be aligned no matter which position they take (on x86 and amd64 at the very least).

"re-interpret the struct to a pointer (length would simply be truncated)."

Wrong. It will be pointer-to-pointer.

Reinterpretation (to treat struct as a pointer to C string) is only possible if you have something like this:

    struct BSTR {
      size_t length;
      WCHAR  chars[N]; // N is length + 1     
    };
and you return pointer to chars[0]. This is so called Basic string - BSTR is a WCHAR* pointer to memory location prepended by string length field.

Re: .NET Standard 2.1

#97

Post by int0x80 »

twblalock wrote: post #15

I thought the Java framework nomenclature was bad, but .Net is way more confusing.

I was thinking about this... but I'm not so sure :)

JRE, JDK, Java EE, Java SE, Beans, Enterprise Beans, Managed Beans, JEE APIs vs Implementations etc, containers, app containers, app servers.

'Enterprise' has to be the worst prefix/name ever for an API or technology.

It is a tough contest.

Re: .NET Standard 2.1

#98

Post by hornetblack »

maxxxxx wrote: post #90
qwerty456127 wrote: post #89

Earlier quoted context omitted.

> The "desktop app packs" for WPF and WinForms WinForms work quite nice on Linux with Mono. Won't they cooperate?

I think Mono Winforms is a total rewrite of the Windows Winforms. There is no shared code.

It's shared with WINE I believe. (The native parts)

Re: .NET Standard 2.1

#99

Post by maxxxxx »

qwerty456127 wrote: post #94
maxxxxx wrote: post #90

Earlier quoted context omitted.

I think Mono Winforms is a total rewrite of the Windows Winforms. There is no shared code.

Sure it is but why not use that code to let .Net Core support WinForms on Linux the way it is going to support it on Windows?

I think you have that a little backwards. This is not up to the Core developers but to the Mono developers. There is nothing preventing the Mono developers from supporting .Net Core.

Re: .NET Standard 2.1

#100

Post by c-smile »

pjmlp wrote: post #86
c-smile wrote: post #26

So they added Span as a big thing ... > (Span is) at the heart of most performance-related improvements in .NET Core 2.1. Since it allows managing buffers in a more efficient way, it can help in reducing allocations and copying. We consider Span to be a very fundamental type as it requires runtime and compiler support in order to be fully leveraged. Small struct that is declared as public readonly ref struct Span { p…

Well, to be fair Modula-3 and Eiffel did it first. And I bet Sciter is younger than any of them.

Would you mind to provide some link that illustrates what you mean exactly?
Post reply on HN