By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,949 Members | 950 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,949 IT Pros & Developers. It's quick & easy.

Standards

P: n/a
Hi,

What is the status on the "standardization" (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
Jul 19 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
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 "standardization" (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

Jul 19 '05 #2

P: n/a
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" <Ro********@student.tul.edu> wrote in message
news:#3**************@TK2MSFTNGP10.phx.gbl...
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 "standardization" (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


Jul 19 '05 #3

P: n/a
AFIAK, the ECMA standards do not in any way cover Winforms.

-cd

Umpa Lumpa wrote:
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" <Ro********@student.tul.edu> wrote in message
news:#3**************@TK2MSFTNGP10.phx.gbl...
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 "standardization" (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

Jul 19 '05 #4

P: n/a
Hi,

Umpa Lumpa wrote:
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.


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
Jul 19 '05 #5

P: n/a
Then why the heck are they under the System.* namespace and not Microsoft.*?
"Carl Daniel [VC++ MVP]" <cp******@nospam.mvps.org> wrote in message
news:Ov**************@TK2MSFTNGP12.phx.gbl...
AFIAK, the ECMA standards do not in any way cover Winforms.

-cd

Umpa Lumpa wrote:
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" <Ro********@student.tul.edu> wrote in message
news:#3**************@TK2MSFTNGP10.phx.gbl...
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 "standardization" (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


Jul 19 '05 #6

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

Recipe for disaster

"Peter Vidler" <pv*****@gawab.com> wrote in message
news:FM******************@newsfep2-gui.server.ntli.net...
Hi,

Umpa Lumpa wrote:
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.
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

Jul 19 '05 #7

P: n/a
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:
Then why the heck are they under the System.* namespace and not
Microsoft.*?
"Carl Daniel [VC++ MVP]" <cp******@nospam.mvps.org> wrote in message
news:Ov**************@TK2MSFTNGP12.phx.gbl...
AFIAK, the ECMA standards do not in any way cover Winforms.


Jul 19 '05 #8

P: n/a
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,namespace names are not part of
the standard.

Willy.
Jul 19 '05 #9

P: n/a
I suggest they change it or make it portable.

"Umpa Lumpa" <po********@127.0.0.129> wrote in message
news:e1**************@tk2msftngp13.phx.gbl...
So why the heck are they in teh System.* namespace and NOT the Microsoft.*
(ie., VendorSpecific.* ) namespaces?

Recipe for disaster

"Peter Vidler" <pv*****@gawab.com> wrote in message
news:FM******************@newsfep2-gui.server.ntli.net...
Hi,

Umpa Lumpa wrote:
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.


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


Jul 19 '05 #10

P: n/a
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" <po********@127.0.0.129> wrote in message
news:e1**************@tk2msftngp13.phx.gbl...
So why the heck are they in teh System.* namespace and NOT the Microsoft.*
(ie., VendorSpecific.* ) namespaces?

Recipe for disaster

"Peter Vidler" <pv*****@gawab.com> wrote in message
news:FM******************@newsfep2-gui.server.ntli.net...
Hi,

Umpa Lumpa wrote:
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.


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


Jul 19 '05 #11

P: n/a
Umpa Lumpa wrote:
Then why the heck are they under the System.* namespace and not
Microsoft.*?


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.
Jul 19 '05 #12

P: n/a
People are under the impression WinForms is portable , yet it is not the
case. (100%).
"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote in message
news:eY**************@TK2MSFTNGP09.phx.gbl...
Umpa Lumpa wrote:
Then why the heck are they under the System.* namespace and not
Microsoft.*?
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.

Jul 19 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.