What's Wrong with the Windows API?

[John Smith]

In: MSDN Visual Studio .Net 2003

Article: Replacing API Calls with .NET Framework Classes

What's Wrong with the Windows API?
...
... The .NET common language runtime is meant to be platform non-specific ...
...
Working with the Registry
...

Questions:
1. Can I use the framework registry functions with OS/2, MAC, ...?
2. Is System.Windows.Forms a platform independent namespace?
3. The other systems standard controls look like and behave as the
windows controls?

 

[Jeremy Todd]

Questions:
1. Can I use the framework registry functions with OS/2, MAC, ...?

OS/2? Does that still exist? But the answer is no.

2. Is System.Windows.Forms a platform independent namespace?

No. .NET is somewhat -more- platform independent than previous
Microsoft programming paradigms, but, while some namespaces may be
successfully ported to other platforms, I seriously doubt Windows Forms will
ever work right anywhere else. Microsoft originally intended .NET to have a
role similar to Java, but then backpedaled, and now say that .NET and
Windows are synonymous.

3. The other systems standard controls look like and behave as the
windows controls?

As far as I know, there are no standard controls for other systems.
Even if the managed portion of the System.Windows.Forms namespace is ported
to other platforms, you'll still run into a lot of problems, because most
programmers feel free to assume there is a Windows machine underneath, and
do things like override WndProc with Windows API-specific operations. I
wouldn't count on .NET ever being fully cross-platform.

Jeremy

 

[John Smith]

ever work right anywhere else. Microsoft originally intended .NET to have a
role similar to Java, but then backpedaled, and now say that .NET and
Windows are synonymous.

I am glad to read that

As far as I know, there are no standard controls for other systems.
Even if the managed portion of the System.Windows.Forms namespace is ported
to other platforms, you'll still run into a lot of problems, because most
programmers feel free to assume there is a Windows machine underneath, and
do things like override WndProc with Windows API-specific operations. I
wouldn't count on .NET ever being fully cross-platform.

Jeremy

Do you know if the new vb (vb 2005 or whatever) will have a better
support for API calls? And UDTs?

 

[Tom Shelton]

I am glad to read that

Do you know if the new vb (vb 2005 or whatever) will have a better
support for API calls? And UDTs?

What's your issue with the support now for API calls? If anything, I've
found that using the API's from VB.NET to be far supperior to VB6.

 

[Cor]

Hi John,

I think you do not understand multiplatform,

That does not mean that it should support every good or dump OS that once
was made or will be made.

In my opinion it means that it is able to support more than one platform and
absolutly not all.

Cor

 

[John Smith]

What's your issue with the support now for API calls? If anything, I've
found that using the API's from VB.NET to be far supperior to VB6.

UDTs as API parameters
Please see another of my posts: Derived classes cannot raise base class
events????

 

[Tom Shelton]

UDTs as API parameters

Not an issue. Again, the support is better then VB6.

Please see another of my posts: Derived classes cannot raise base class
events????

I'm looking at it - but it seems to be a little vauge. Can you be a
little more specific?

 

[John Smith]

I'm looking at it - but it seems to be a little vauge. Can you be a
little more specific?

Take a listbox as example
Since the framework base listbox is itself an inherited windows listbox,
whenever you use the system API to change the selected items the
ListBox1.SelectedItems will allways return nothing while
ListBox1.SelectedItems.Count returns non zero