Portability

  • Thread starter Thread starter Mr.Tickle
  • Start date Start date
M

Mr.Tickle

What classes are portable and what are not, I would say WinForms is NOT
portable, what others are not portable?
 
Can you be more specific as to what kind of "portability"
you're interested in? For C++ code, "portable" might mean
that I want to compile the same code using different
compilers, &/or to run on different machine architectures
(PC/Mac) &/or OS's. But I'm not sure those definitions
apply to a .NET program.
 
portable as in runs on ANY .net runtime anywhere anytime . Not dependant on
WINE or other such crap.

Pure portable in the runtime.
 
Mr.Tickle said:
What classes are portable and what are not, I would say WinForms is NOT
portable, what others are not portable?
Click to expand...
Winforms is portable, but its likely not worth the effort(it would require a
codebase capable of emulating and operating like windows does). . Umm, the
AxImport class is likely not portable(can't think of the actual name), any
classes under Microsoft.* are not directly portable(but there is no reason
someone couldn't implement a set of registery classes that doesn't use the
registry, say in mono).
Some of the various com interop classes may not be(or may not have any real
reason to be), System.EnterpriseServices may or may not be.
Beyond that, there is little I can think of that would be definatly
not-portable. Why not go to monos website and see waht they didn't manage to
port?
 
BZZZT wrong.

No its not portable, it uses pinvoke heavily, thats why Mono on linux
requires WINE to run.
 
Mr.Tickle said:
BZZZT wrong.

No its not portable, it uses pinvoke heavily, thats why Mono on linux
requires WINE to run.
Click to expand...
Depends on what you want to do, do you literally mean run the
System.Windows.Forms.dll? if so, you are just way to out there to even
bother answering, that is a windows dll, it'd be a silly idea to run any of
the framework provided assemblies nativly, they aren't meant to port across
runtimes any more than the JIT is.

Now, if you are not capable of imagining such a simple thing as re-writing
the assembly without using PInvoke(or PInvoking to a completly different set
of libraries), then you are severely lacking and should choose another
career path. Concept and\or interface portablility has NOTHING to do with
implementation portability. Sometimes implementations may not port while the
concept and interface can be ported with some work.
Porting the code to use another system, GTK for example(which mono is
attempting), while dropping very few features is very possible. Those
features that would be dropped you shouldn't be using anyway, they would
include things like messsages and overriding the windows proc, which is
obviously platform specific. Even dropping SendMessage and WndProc support
wouldn't break 95% of code, even that which is using it, some simply
wouldn't work, like forcing RichTextBox to print via the FORMATRANGE
message. Any code that relies on functionality that is platform specific was
designed with that in mind, I can assure you; or designed by people who
don't even know about mono, that depends on the situation.

You both need to actually do research before you respond rudely and learn to
think and imagine on your own. Things can almost always be achieved in
multiple ways, assuming otherwise just limits your abilities and will keep
you from solving many of the problems that you come across.
 
GTK, never, its ugly.



Daniel O'Connell said:
Depends on what you want to do, do you literally mean run the
System.Windows.Forms.dll? if so, you are just way to out there to even
bother answering, that is a windows dll, it'd be a silly idea to run any of
the framework provided assemblies nativly, they aren't meant to port across
runtimes any more than the JIT is.

Now, if you are not capable of imagining such a simple thing as re-writing
the assembly without using PInvoke(or PInvoking to a completly different set
of libraries), then you are severely lacking and should choose another
career path. Concept and\or interface portablility has NOTHING to do with
implementation portability. Sometimes implementations may not port while the
concept and interface can be ported with some work.
Porting the code to use another system, GTK for example(which mono is
attempting), while dropping very few features is very possible. Those
features that would be dropped you shouldn't be using anyway, they would
include things like messsages and overriding the windows proc, which is
obviously platform specific. Even dropping SendMessage and WndProc support
wouldn't break 95% of code, even that which is using it, some simply
wouldn't work, like forcing RichTextBox to print via the FORMATRANGE
message. Any code that relies on functionality that is platform specific was
designed with that in mind, I can assure you; or designed by people who
don't even know about mono, that depends on the situation.

You both need to actually do research before you respond rudely and learn to
think and imagine on your own. Things can almost always be achieved in
multiple ways, assuming otherwise just limits your abilities and will keep
you from solving many of the problems that you come across.
Click to expand...
 
Mr.Tickle said:
GTK, never, its ugly.
Click to expand...
And that matters? Go to monos site and look, they are working on a limited
branch of System.Windows.Forms using GTK#. Its unfortunate, but thats what
your stuck with if you want cross platform. Sadly, swing is probably the
best of the cross platform toolkits.
 
The System namespace should be standardised to PORTABLE libraries.

Winforms should be either portable or if not, under the Microsoft.*
namespace (Vendor.blah.*)

Namespaces are not part of the language specification, fair enough but they
should be standardised as alot of code is dependant on them. Even coding a
console application is not guranteed as these namespaces are not
standardised. They maybe defacto standard but nowhere are they under any
specification.
 
Mr.Tickle said:
The System namespace should be standardised to PORTABLE libraries.

Winforms should be either portable or if not, under the Microsoft.*
namespace (Vendor.blah.*)

Namespaces are not part of the language specification, fair enough but they
should be standardised as alot of code is dependant on them. Even coding a
console application is not guranteed as these namespaces are not
standardised. They maybe defacto standard but nowhere are they under any
specification.
Click to expand...

As far as I know, System.Windows.Forms is not standardized in any manner.
However, it is possible to port it, you just, obviously, cannot use the
win32 api to do so. Things will likely change alot with v2 and avalon as
well.
I don't know if Avalon is a system level thing or if it is wholy at the
managed level(probably system level). When it comes down to it, designing
Winforms as totally portable would end us with something like GTK or Swing,
in other words degrade the look, speed, and capabilities of winforms on the
windows system(which was the target) as well as delaying the release of .NET
another year or two. That choice would not have made sense for anyone
involved and it actually would probably have killed off any chance winforms
had. Most developers probably don't care if their app will run on mono at
this point, those that do will be happy with whatever mono can bring them,
using Wine or using GTK#.
Maybe someday, hell maybe with Avalon(it promises no message pumps after
all), winforms will be portable across systems if someone is willing to put
the implementation into it, maybe. But, until a cross platform winforms
actually reaches a point where it provides more functionality and speed than
native win32 controls, it would not be a choice for most developers, and
definatly not a choice for endusers.
 
The System namespace should be standardised to PORTABLE libraries.

Winforms should be either portable or if not, under the Microsoft.*
namespace (Vendor.blah.*)

Namespaces are not part of the language specification, fair enough but
they should be standardised as alot of code is dependant on them.
Even coding a console application is not guranteed as these namespaces
are not standardised. They maybe defacto standard but nowhere are
they under any specification.
Click to expand...

How some class/library is implemented in the windows version of .NET has
NOTHING to do with if YOUR code that uses it is portable. If another
platform also implements that class/library with the same interfaces then
your code would still compile on the other platform.

The only members in specific classes that will not port are ones that have a
platform specific datatype in the definition. And then for YOUR code not to
port you would have to use that member that is not supported on the other
platform.

Why should you care HOW System.Windows.Forms is implemented on other
platforms. As long as your code compiles and runs the same on it, who
cares!?

As you write your code, you'll have to check the other platforms you want to
support to see that each class member you want to use is or will be
supported.

Michael Lang, MCSD
 
Number one reason not to support Linux is WINE dependancy.

Sure we will ship .net code, it runs on mono, fine, no support for j00 .
 
Mr.Tickle said:
IT may compile but it sure wont run without WINE.
Click to expand...
here is a direct quote from go-mono.com:
<quote>
Gtk# based: This effort will build a subset of Windows.Forms that uses Gtk#.
This gives a better integration with the desktop, but will not be completely
compatible with the Windows edition. In particular code that uses P/Invoke
to call into Win32 or overwrite the Wndproc method to achieve special
effects will not work.
</quote>

Now, tell me, how does that require WINE, aslong as you don't use WndProc or
pinvoke(which are both obviously windows specific). You really need to
actually TRY to read and understand instead of just bantering about things
you obviously havn't tried to research.
 
but will not be completely
compatible with the Windows edition


Says enuf to warant not supporting it.
 
"NOT COMPLETELY COMPATIBLE" back to my main point, mr fluckwad. There goes
yer PORTABILTY.
 
Back
Top