Standards

[Umpa Lumpa]

Hi,

What is the status on the "standardizatio n" (outside MS) of the BCLs?

Is everything under the System namespace going to be "standard" and
everything under the Microsoft namespace custom per MS specific and in
general Vendor.* namespaces for vendor specific classes.

Is WinForms etc planned to be part of this "standard" or will it be not
very portable and therefore should belong under the Microsoft.* namespace?

Thanks

[Rob Tillie]

Re: Standards

You can look at ISO and ECMA in the specs what is standardized.

http://msdn.microsoft.com/net/ecma/

Mainly the CLR and the System namespace I believe.
Well, Mono is trying to get an exact behaviour in porting almost any
namespace, wo that shouldn't be a problem.

Greetz,
-- Rob.

Umpa Lumpa wrote:[color=blue]
> Hi,
>
> What is the status on the "standardizatio n" (outside MS) of the
> BCLs?
>
> Is everything under the System namespace going to be "standard" and
> everything under the Microsoft namespace custom per MS specific and
> in general Vendor.* namespaces for vendor specific classes.
>
> Is WinForms etc planned to be part of this "standard" or will it be
> not very portable and therefore should belong under the Microsoft.*
> namespace?
>
> Thanks[/color]

[Umpa Lumpa]

Re: Standards

My concern is WinForms etc because on MONO that is taking 2 paths, P/Invoke
to win32 (and therefore WINE dependant) and GTK# (but less compatible).
That to me indicates NON STANDARD.


"Rob Tillie" <Rob.Tillie@stu dent.tul.edu> wrote in message
news:#36KqsBaDH A.2404@TK2MSFTN GP10.phx.gbl...[color=blue]
> You can look at ISO and ECMA in the specs what is standardized.
> http://msdn.microsoft.com/net/ecma/
>
> Mainly the CLR and the System namespace I believe.
> Well, Mono is trying to get an exact behaviour in porting almost any
> namespace, wo that shouldn't be a problem.
>
> Greetz,
> -- Rob.
>
> Umpa Lumpa wrote:[color=green]
> > Hi,
> >
> > What is the status on the "standardizatio n" (outside MS) of the
> > BCLs?
> >
> > Is everything under the System namespace going to be "standard" and
> > everything under the Microsoft namespace custom per MS specific and
> > in general Vendor.* namespaces for vendor specific classes.
> >
> > Is WinForms etc planned to be part of this "standard" or will it be
> > not very portable and therefore should belong under the Microsoft.*
> > namespace?
> >
> > Thanks[/color]
>
>[/color]

[Carl Daniel [VC++ MVP]]

Re: Standards

AFIAK, the ECMA standards do not in any way cover Winforms.

-cd

Umpa Lumpa wrote:[color=blue]
> My concern is WinForms etc because on MONO that is taking 2 paths,
> P/Invoke to win32 (and therefore WINE dependant) and GTK# (but less
> compatible). That to me indicates NON STANDARD.
>
>
> "Rob Tillie" <Rob.Tillie@stu dent.tul.edu> wrote in message
> news:#36KqsBaDH A.2404@TK2MSFTN GP10.phx.gbl...[color=green]
>> You can look at ISO and ECMA in the specs what is standardized.
>> http://msdn.microsoft.com/net/ecma/
>>
>> Mainly the CLR and the System namespace I believe.
>> Well, Mono is trying to get an exact behaviour in porting almost any
>> namespace, wo that shouldn't be a problem.
>>
>> Greetz,
>> -- Rob.
>>
>> Umpa Lumpa wrote:[color=darkred]
>>> Hi,
>>>
>>> What is the status on the "standardizatio n" (outside MS) of the
>>> BCLs?
>>>
>>> Is everything under the System namespace going to be "standard"
>>> and everything under the Microsoft namespace custom per MS
>>> specific and in general Vendor.* namespaces for vendor specific
>>> classes.
>>>
>>> Is WinForms etc planned to be part of this "standard" or will it
>>> be not very portable and therefore should belong under the
>>> Microsoft.* namespace?
>>>
>>> Thanks[/color][/color][/color]

[Peter Vidler]

Re: Standards

Hi,

Umpa Lumpa wrote:[color=blue]
> My concern is WinForms etc because on MONO that is taking 2 paths,
> P/Invoke to win32 (and therefore WINE dependant) and GTK# (but less
> compatible). That to me indicates NON STANDARD.[/color]

Standards are not the problem (not the only problem, anyway). There is quite
a lot of Windows Forms functionality that requires P/Invoke or WndProc
overrides to get to. These cannot be compatible with linux (they use builtin
windows dll's or procedures). This is why wine is the best way to go atm for
compatibility.

Pete

[Umpa Lumpa]

Re: Standards

Then why the heck are they under the System.* namespace and not Microsoft.*?


"Carl Daniel [VC++ MVP]" <cpdaniel@nospa m.mvps.org> wrote in message
news:OvsPirCaDH A.1744@TK2MSFTN GP12.phx.gbl...[color=blue]
> AFIAK, the ECMA standards do not in any way cover Winforms.
>
> -cd
>
> Umpa Lumpa wrote:[color=green]
> > My concern is WinForms etc because on MONO that is taking 2 paths,
> > P/Invoke to win32 (and therefore WINE dependant) and GTK# (but less
> > compatible). That to me indicates NON STANDARD.
> >
> >
> > "Rob Tillie" <Rob.Tillie@stu dent.tul.edu> wrote in message
> > news:#36KqsBaDH A.2404@TK2MSFTN GP10.phx.gbl...[color=darkred]
> >> You can look at ISO and ECMA in the specs what is standardized.
> >> http://msdn.microsoft.com/net/ecma/
> >>
> >> Mainly the CLR and the System namespace I believe.
> >> Well, Mono is trying to get an exact behaviour in porting almost any
> >> namespace, wo that shouldn't be a problem.
> >>
> >> Greetz,
> >> -- Rob.
> >>
> >> Umpa Lumpa wrote:
> >>> Hi,
> >>>
> >>> What is the status on the "standardizatio n" (outside MS) of the
> >>> BCLs?
> >>>
> >>> Is everything under the System namespace going to be "standard"
> >>> and everything under the Microsoft namespace custom per MS
> >>> specific and in general Vendor.* namespaces for vendor specific
> >>> classes.
> >>>
> >>> Is WinForms etc planned to be part of this "standard" or will it
> >>> be not very portable and therefore should belong under the
> >>> Microsoft.* namespace?
> >>>
> >>> Thanks[/color][/color]
>
>[/color]

[Umpa Lumpa]

Re: Standards

So why the heck are they in teh System.* namespace and NOT the Microsoft.*
(ie., VendorSpecific. * ) namespaces?

Recipe for disaster

"Peter Vidler" <pvidler@gawab. com> wrote in message
news:FM91b.498$ Dg4.214906@news fep2-gui.server.ntli .net...[color=blue]
> Hi,
>
> Umpa Lumpa wrote:[color=green]
> > My concern is WinForms etc because on MONO that is taking 2 paths,
> > P/Invoke to win32 (and therefore WINE dependant) and GTK# (but less
> > compatible). That to me indicates NON STANDARD.[/color]
>
> Standards are not the problem (not the only problem, anyway). There is[/color]
quite[color=blue]
> a lot of Windows Forms functionality that requires P/Invoke or WndProc
> overrides to get to. These cannot be compatible with linux (they use[/color]
builtin[color=blue]
> windows dll's or procedures). This is why wine is the best way to go atm[/color]
for[color=blue]
> compatibility.
>
> Pete
>
>[/color]

[Carl Daniel [VC++ MVP]]

Re: Standards

Wild guess -

Because the hierarchy of namespaces was put together before the decision to
submit the BCL and CLR to ECMA was finalized. I suppose they could have
chosen the typical Java solution - duplicate everything into another
namespace and deprecate it in the System namespace, while retaining it
forever for backwards compatibility.

-cd

Umpa Lumpa wrote:[color=blue]
> Then why the heck are they under the System.* namespace and not
> Microsoft.*?
>
>
> "Carl Daniel [VC++ MVP]" <cpdaniel@nospa m.mvps.org> wrote in message
> news:OvsPirCaDH A.1744@TK2MSFTN GP12.phx.gbl...[color=green]
>> AFIAK, the ECMA standards do not in any way cover Winforms.[/color][/color]

[Willy Denoyette [MVP]]

Re: Standards

Umpa Lumpa wrote:
|| So why the heck are they in teh System.* namespace and NOT the
|| Microsoft.* (ie., VendorSpecific. * ) namespaces?
||
|| Recipe for disaster
||

Please take some time and read the standard documents. The standard defines profiles and libraries,names pace names are not part of
the standard.

Willy.

[Umpa Lumpa]

Re: Standards

I suggest they change it or make it portable.



"Umpa Lumpa" <postmaster@127 .0.0.129> wrote in message
news:e1Ixa3CaDH A.2476@tk2msftn gp13.phx.gbl...[color=blue]
> So why the heck are they in teh System.* namespace and NOT the Microsoft.*
> (ie., VendorSpecific. * ) namespaces?
>
> Recipe for disaster
>
> "Peter Vidler" <pvidler@gawab. com> wrote in message
> news:FM91b.498$ Dg4.214906@news fep2-gui.server.ntli .net...[color=green]
> > Hi,
> >
> > Umpa Lumpa wrote:[color=darkred]
> > > My concern is WinForms etc because on MONO that is taking 2 paths,
> > > P/Invoke to win32 (and therefore WINE dependant) and GTK# (but less
> > > compatible). That to me indicates NON STANDARD.[/color]
> >
> > Standards are not the problem (not the only problem, anyway). There is[/color]
> quite[color=green]
> > a lot of Windows Forms functionality that requires P/Invoke or WndProc
> > overrides to get to. These cannot be compatible with linux (they use[/color]
> builtin[color=green]
> > windows dll's or procedures). This is why wine is the best way to go atm[/color]
> for[color=green]
> > compatibility.
> >
> > Pete
> >
> >[/color]
>
>[/color]

[Umpa Lumpa]

Re: Standards

Then again what is to stop somebody implementing a method by method feature
by feature replacemetn that IS portable as System.WinForms .blah .dll?


"Umpa Lumpa" <postmaster@127 .0.0.129> wrote in message
news:e1Ixa3CaDH A.2476@tk2msftn gp13.phx.gbl...[color=blue]
> So why the heck are they in teh System.* namespace and NOT the Microsoft.*
> (ie., VendorSpecific. * ) namespaces?
>
> Recipe for disaster
>
> "Peter Vidler" <pvidler@gawab. com> wrote in message
> news:FM91b.498$ Dg4.214906@news fep2-gui.server.ntli .net...[color=green]
> > Hi,
> >
> > Umpa Lumpa wrote:[color=darkred]
> > > My concern is WinForms etc because on MONO that is taking 2 paths,
> > > P/Invoke to win32 (and therefore WINE dependant) and GTK# (but less
> > > compatible). That to me indicates NON STANDARD.[/color]
> >
> > Standards are not the problem (not the only problem, anyway). There is[/color]
> quite[color=green]
> > a lot of Windows Forms functionality that requires P/Invoke or WndProc
> > overrides to get to. These cannot be compatible with linux (they use[/color]
> builtin[color=green]
> > windows dll's or procedures). This is why wine is the best way to go atm[/color]
> for[color=green]
> > compatibility.
> >
> > Pete
> >
> >[/color]
>
>[/color]

[Brandon Bray [MSFT]]

Re: Standards

Umpa Lumpa wrote:[color=blue]
> Then why the heck are they under the System.* namespace and not
> Microsoft.*?[/color]

It shouldn't matter what namespace is chosen. When using types in a program,
the type not only includes the namespace but also the name of the assembly.
This is a huge improvement over previous standards choices. Reserving a
namespace for the purpose of a standard is an easy way to create a mess.

Because the namespace of a type includes the assembly name, several
assemblies (even in the same program) can use the same namespace name with
completely different types. It does not hinder the progress of other library
vendors.

If you are concerned about ensuring your program is portable using only the
features of the ECMA and ISO standards, you can build and run the program
with the Shared Source CLI implementation.

Of course, I don't work on the frameworks, so I can't say with any authority
as to why they chose the namespaces they did. All I can say is that it
shouldn't have any impact on developers, they should just be usable.

Cheerio!

--
Brandon Bray Visual C++ Compiler
This posting is provided AS IS with no warranties, and confers no rights.

[Mr.Tickle]

Re: Standards

People are under the impression WinForms is portable , yet it is not the
case. (100%).


"Brandon Bray [MSFT]" <branbray@onlin e.microsoft.com > wrote in message
news:eYk0sWRaDH A.2620@TK2MSFTN GP09.phx.gbl...[color=blue]
> Umpa Lumpa wrote:[color=green]
> > Then why the heck are they under the System.* namespace and not
> > Microsoft.*?[/color]
>
> It shouldn't matter what namespace is chosen. When using types in a[/color]
program,[color=blue]
> the type not only includes the namespace but also the name of the[/color]
assembly.[color=blue]
> This is a huge improvement over previous standards choices. Reserving a
> namespace for the purpose of a standard is an easy way to create a mess.
>
> Because the namespace of a type includes the assembly name, several
> assemblies (even in the same program) can use the same namespace name with
> completely different types. It does not hinder the progress of other[/color]
library[color=blue]
> vendors.
>
> If you are concerned about ensuring your program is portable using only[/color]
the[color=blue]
> features of the ECMA and ISO standards, you can build and run the program
> with the Shared Source CLI implementation.
>
> Of course, I don't work on the frameworks, so I can't say with any[/color]
authority[color=blue]
> as to why they chose the namespaces they did. All I can say is that it
> shouldn't have any impact on developers, they should just be usable.
>
> Cheerio!
>
> --
> Brandon Bray Visual C++ Compiler
> This posting is provided AS IS with no warranties, and confers no rights.
>
>[/color]