nemesis wrote:
> probably and sadly yes.  Because it was made to run on a single OS from a single
> company.  Many choices and tradeoffs are easier to make as is making it work
> nice with the underlying architecture.

Other than some of the low-level windowing stuff, what do you see in the 
.NET libraries that would be difficult to implement on (say) Linux?

The only bits I've seen that are actually Windows-specific were the bits 
that were either accessing directly the win32 stuff (like turning off 
particular windows message pump messages), which you don't need to do. 
Or stuff that Linux doesn't support anyway, like distributed 
transactions. (E.g., AFAIK, you can't write code in Linux to rename 
three files from A,B,C to D,E,F in such a way that nobody ever sees D 
without seeing F, and a powerfailure after you rename A and before you 
rename C undoes the renames you've done so far.)

The stuff you'd expect to be portable (web stuff, file stuff, threads, 
data structures, code generation, library management, temp files, etc) 
are all quite portable.  Just off the top of my head, I'd say maybe 10% 
of the library routines, tops, have an API or functionality that makes 
them hard to port, and maybe 1% have an API or functionality that makes 
them hard to port to an OS that actually supports that kind of 
functionality.

Of course, it's *difficult* to port the windowing stuff, but that 
doesn't mean it's inherently non-portable. Only that it's complex. It's 
difficult to make X programs run under Windows, too, without writing an 
X server.

What classes do you think are unportable?

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message