First of all the Java Virtual machine already supports more languages then the MS virtual machine. So far the MS virtual machine supports only c# and some derivative of eiffel.
Not really. In fact, microsoft decided to stop supporting its IActiveScripting Interfaces (perl5, VBscript, JScript) in place of the CLR. VBScript has grown up into VB.NET, and it's really becoming interesting (my most frequent complaint against VBScript was against global var scoped. This has changed to block scope).
on MSDN, there's a interesting paper about fujitsu`s cobol for.net... they supply an Active Server Example... Just try to figure COBOL code within an HTML page with server-side extensions:]
please please... it wasnt DynAny Support into corba, but PHP:) please please... don't hit me... i know i was wrong... excuse me for getting you mad, reader.:) (just kidding. people here like to flame a lot and it really scares me:])
Alghouth heavily object-based, COM isnt' really about subclassing. Its about writing black-boxes and making then available for other black-boxes. COM+ 2.0, the so-called.NET, along with its friends SOAP, C# and Common Language Runtime, are supposed to fill this leak, which is really the only major complain against COM except "DCOM isnt' that open" (well... its hard to implement DCOM support on anything except windows). Thats' something SOAP and UDDI are trying to overcome. Well. COM as good advantages. You can take an ActiveX Component for Active Scripting and Mix with MSXML, and you'll have ASP. Try implement DynAny support into corba, make loads of gnome/orbit modules available, and make Balsa/Evolution posts/agenda available on the web. Thats' something really hard to do with the heterogeneous unix world:) (please don't hit me. i'm posting this from a FreeBSD box. Really! I like unix, but there's severe faults, as with Windows:])
I'm about to take my MCSD on Visual C++... coming from a previous UNIX Background and working on integrating both platforms, i'd like to share my thoughts:
First: MFC was portable. Runs on everything NT runs on... runs on CE (albeit limited) and runs on MAC (they even ported OLE to Mac, way before they decided to split up ole and bring up COM)... Its portability doesn depends upon the compiler, as microsoft pointed out on a MSDN article about IE5 on Slowlaris commenting their experience with MainWin. Their main dependence comes not from the compiler: MFC apps can compile under Borland, Watcom, Symantec... Under the language aspects, they're fairly traditional, implementing their own exception system (using setjmp/longjmp). Its not bad. The problem with MFC is that people haven't been separating its goal: its for UI... your UI design shouldn't model your overall (logical?) application design. A good point i always make is, when developing an MFC based app, to design its IDL (for OLE/COM Automation with some help of ATL) and _THEN_, design its interface. The UI becomes an layer for the automation. It helped me implement systems which let me port easily, using CORBA instead of OLE.
And as for language extensions, they're mostly COM-related: #import, runtime classes (not pertinent to MFC neither ATL, but part of MSVCRT.dll), and __declspec/__uuidof, for CLSID/IID tagging within the object code. Btw, it would be neat if g++ could implement modular preprocessors on it, letting me choose (this is an hypothesis)/usr/local/g++/bin/CORBAimport as a handler for #import directives. It could be useful for KDE's moc, for instance.:)
the fine print: god, if you want your shitty level editor to be portable, start using it with JAVA. Its performance will be poor, but it will run. you sucker.:]
Slashdot Mirror
First of all the Java Virtual machine already supports more languages then the MS virtual machine. So far the MS virtual machine supports only c# and some derivative of eiffel.
Not really. In fact, microsoft decided to stop supporting its IActiveScripting Interfaces (perl5, VBscript, JScript) in place of the CLR. VBScript has grown up into VB.NET, and it's really becoming interesting (my most frequent complaint against VBScript was against global var scoped. This has changed to block scope).
on MSDN, there's a interesting paper about fujitsu`s cobol for .net... they supply an Active Server Example... Just try to figure COBOL code within an HTML page with server-side extensions :]
please please... it wasnt DynAny Support into corba, but PHP :) please please... don't hit me... i know i was wrong... excuse me for getting you mad, reader. :) (just kidding. people here like to flame a lot and it really scares me :])
Alghouth heavily object-based, COM isnt' really about subclassing. Its about writing black-boxes and making then available for other black-boxes. COM+ 2.0, the so-called .NET, along with its friends SOAP, C# and Common Language Runtime, are supposed to fill this leak, which is really the only major complain against COM except "DCOM isnt' that open" (well... its hard to implement DCOM support on anything except windows). Thats' something SOAP and UDDI are trying to overcome. Well. COM as good advantages. You can take an ActiveX Component for Active Scripting and Mix with MSXML, and you'll have ASP. Try implement DynAny support into corba, make loads of gnome/orbit modules available, and make Balsa/Evolution posts/agenda available on the web. Thats' something really hard to do with the heterogeneous unix world :) (please don't hit me. i'm posting this from a FreeBSD box. Really! I like unix, but there's severe faults, as with Windows :])
I'm about to take my MCSD on Visual C++... coming from a previous UNIX Background and working on integrating both platforms, i'd like to share my thoughts:
/usr/local/g++/bin/CORBAimport as a handler for #import directives. It could be useful for KDE's moc, for instance. :)
:]
First: MFC was portable. Runs on everything NT runs on... runs on CE (albeit limited) and runs on MAC (they even ported OLE to Mac, way before they decided to split up ole and bring up COM)... Its portability doesn depends upon the compiler, as microsoft pointed out on a MSDN article about IE5 on Slowlaris commenting their experience with MainWin. Their main dependence comes not from the compiler: MFC apps can compile under Borland, Watcom, Symantec... Under the language aspects, they're fairly traditional, implementing their own exception system (using setjmp/longjmp). Its not bad.
The problem with MFC is that people haven't been separating its goal: its for UI... your UI design shouldn't model your overall (logical?) application design. A good point i always make is, when developing an MFC based app, to design its IDL (for OLE/COM Automation with some help of ATL) and _THEN_, design its interface. The UI becomes an layer for the automation. It helped me implement systems which let me port easily, using CORBA instead of OLE.
And as for language extensions, they're mostly COM-related: #import, runtime classes (not pertinent to MFC neither ATL, but part of MSVCRT.dll), and __declspec/__uuidof, for CLSID/IID tagging within the object code. Btw, it would be neat if g++ could implement modular preprocessors on it, letting me choose (this is an hypothesis)
the fine print: god, if you want your shitty level editor to be portable, start using it with JAVA. Its performance will be poor, but it will run. you sucker.