What's Wrong with the Windows API?

  • Thread starter Thread starter John Smith
  • Start date Start date
J

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?
 
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
 
Jeremy said:
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?
 
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.
 
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
 
Tom said:
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????
 
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?
 
Tom said:
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
 
Back
Top