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

101–110 of 124 posts

Re: .NET Standard 2.1

#101

Post by manigandham »

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…

A lack of new features does not mean something is deprecated. That would mean actively discouraging its use, something that doesn't make sense given the sheer amount of code written and the fact that support will continue for years, if not decades.

Re: .NET Standard 2.1

#102

Post by qwerty456127 »

maxxxxx wrote: post #99
qwerty456127 wrote: post #94

Earlier quoted context omitted.

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.

Aren't these the .Net Core developers who sort of import (or re-implement?) WinForms support from the classic .Net Framework on Windows?

Re: .NET Standard 2.1

#103

Post by qwerty456127 »

hornetblack wrote: post #98
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.

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

Wine uses its own Mono instance and I usually run WinForms apps directly with the system Mono set-up without using Wine (although I have both installed).

Re: .NET Standard 2.1

#104

Post by manigandham »

pjmlp wrote: post #85
oaiey wrote: post #54

Earlier quoted context omitted.

I think it is fair to say, that we need to realize, that .NET Core runs on all of the platforms which in Microsoft view have future (.NET Core, Xamarin, Unity and UWP). The only platform no one is really interested (from Microsoft perspective) is the .NET Framework. The .NET Framework is, from Microsoft .NET and WIndows Team perspective, a legacy burden which is unable to innovate, change or improve due to the deploy…

The problem is see is not being able to go to .NET Core because of third party dependencies. And we still have lots of them that until now haven't cared much about .NET Core.

They will start caring now, or will be replaced by ones that do.

Re: .NET Standard 2.1

#105

Post by pjmlp »

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

Earlier quoted context omitted.

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?

Basic examples, a big late to go diving into old documentation.

Modula-3 version:

    GENERIC MODULE Slices(T)

    TYPE
      Slice = RECORD
         start : REF T;  (* If you want the GC out of the way, replace with UNTRACED REF T*)
         length: CARDINAL;
         ...
      END;

    END Slices;
Or one could simply use open arrays:

    TYPE
        Slice = ARRAY OF T
Eiffel version:

    expanded class Slice[T]
       start: detachable T;
       length: INTEGER_32;
       ...
    end
Naturally, one would use Array[T].slice() instead.

http://smarteiffel.loria.fr/libraries/api/lib.d/storage.d/lo...

Re: .NET Standard 2.1

#106

Post by hnbroseph »

i really wish they would say "the .net standard" rather than just ".net standard". missing that prefixed article is confusing for someone not in the ecosystem (or me at least).

even better would be "specification" rather than "standard", the later being a word frequently used to indicate a particular version of some thing.

Re: .NET Standard 2.1

#107

Post by terrajobst »

hnbroseph wrote: post #106

i really wish they would say "the .net standard" rather than just ".net standard". missing that prefixed article is confusing for someone not in the ecosystem (or me at least). even better would be "specification" rather than "standard", the later being a word frequently used to indicate a particular version of some thing.

Totally fair. The original name was ".NET Standard Library" but we were too lazy so we shortened it to just ".NET Standard", which then ended up becoming the product name.

Re: .NET Standard 2.1

#108

Post by c-smile »

pjmlp wrote: post #105
c-smile wrote: post #100

Earlier quoted context omitted.

Would you mind to provide some link that illustrates what you mean exactly?

Basic examples, a big late to go diving into old documentation. Modula-3 version: GENERIC MODULE Slices(T) TYPE Slice = RECORD start : REF T; (* If you want the GC out of the way, replace with UNTRACED REF T*) length: CARDINAL; ... END; END Slices; Or one could simply use open arrays: TYPE Slice = ARRAY OF T Eiffel version: expanded class Slice[T] start: detachable T; length: INTEGER_32; ... end Naturally, one would…

Yeah, thanks a lot. That is really it. Same as in D lang. In fact D's array is just a slice. At least it used to be so 10 years ago. GC there does the rest - as in Modula-3.

Re: .NET Standard 2.1

#109

Post by simonh »

qwerty456127 wrote: post #24
michaelwda wrote: post #20

Earlier quoted context omitted.

This is coming in .NET Core 3. Slated for Q1 2019 AFAIK. https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...

If WPF is coming in .NET Core, does this mean we are going to be able to run WPF apps on Linux and Mac?

There will be a desktop pack that extends Core with windows desktop application technologies. Bear in mind these are really .NET API wrappers round the underlying Windows systems, so since those underlying libraries and such don’t exist on Mac or Linux .NET APIs won’t have anything to provide access to.

Think if it this way. Someone could write a .NET Core wrapper round the MacOS GUI libraries and platform APIs, but you couldn’t run that on Windows.

Re: .NET Standard 2.1

#110

Post by zamalek »

c-smile wrote: post #96
zamalek wrote: post #84

Earlier quoted context omitted.

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

That's not what I was going after. You can treat the memory location (where the structure resides) as a pointer, plan and simple, nothing more fancy than what I said.
Post reply on HN