- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've seen some mentioning of Microcoft and their .NET strategy, and am curious as to the status of Visual Fortran and .NET. Some issues are:
* Common development environment with Visual Basic, Visual C++, etc.? (Makes mixed lanuage development simpler; good environment)
* COM/DCOM --> some XML techniques, avoiding the Registry.
* What about execution speed? What are the penalties of using the "byte code" intermediate step? Can this problem be removed by generating "machine code" executables, and maintaining the advantages of the .NET strategy?
* Can the GUI builder of Visual Studio be used with Visual Fortran in such an (assumed) development tool?
-Bernt Lie
* Common development environment with Visual Basic, Visual C++, etc.? (Makes mixed lanuage development simpler; good environment)
* COM/DCOM --> some XML techniques, avoiding the Registry.
* What about execution speed? What are the penalties of using the "byte code" intermediate step? Can this problem be removed by generating "machine code" executables, and maintaining the advantages of the .NET strategy?
* Can the GUI builder of Visual Studio be used with Visual Fortran in such an (assumed) development tool?
-Bernt Lie
Link Copied
8 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have been hearing and reading some about the .NET environment, but I didn't think of how CVF would fit in until I read Bernt's post.
From what little I know, .NET will be using the next generation of Microsoft's IDE (Developer Studio 7?). Will Compaq release a version of CVF that will be compatible with that IDE?
I think that VC++ will still be available, but Microsoft will release the new C# language as a part of .NET. Will C# and CVF programs be able to call each other? Will doing so be more or less difficult than it is now working with VC++? Will it still be possible for VB programs to call CVF programs in the .NET environment?
Mike Durisin
From what little I know, .NET will be using the next generation of Microsoft's IDE (Developer Studio 7?). Will Compaq release a version of CVF that will be compatible with that IDE?
I think that VC++ will still be available, but Microsoft will release the new C# language as a part of .NET. Will C# and CVF programs be able to call each other? Will doing so be more or less difficult than it is now working with VC++? Will it still be possible for VB programs to call CVF programs in the .NET environment?
Mike Durisin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are working toward having Visual Fortran share the new development environment with Visual C++ - it is a major change in the way Developer Studio works, but we've been at this for a long time now and think that the changes will bring some benefits to Fortran users.
Our goal is to continue to provide the ability to have mixed-language applications using Visual Fortran. That is unlilkely to mean that VF will generate .NET byte code - this has too many disadvantages for typical Fortran applications. We believe that you will be able to mix .NET and CVF code in an application.
We're continuing to look at what we can do to make it easy to take advantage of .NET features, including strengthening our existing COM support. If you ask us again in a few months, we may be able to say more.
Steve
Our goal is to continue to provide the ability to have mixed-language applications using Visual Fortran. That is unlilkely to mean that VF will generate .NET byte code - this has too many disadvantages for typical Fortran applications. We believe that you will be able to mix .NET and CVF code in an application.
We're continuing to look at what we can do to make it easy to take advantage of .NET features, including strengthening our existing COM support. If you ask us again in a few months, we may be able to say more.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. As .NET isn't COM-based, why is strengthening CVF's COM support a priority for its exploitation of VS.NET (or whatever it's called this week)?
2. Will CVF be link-compatible with managed VS.NET code (C# or VB)? How about VB.NET-generated unmanaged C++?
Gerry T.
2. Will CVF be link-compatible with managed VS.NET code (C# or VB)? How about VB.NET-generated unmanaged C++?
Gerry T.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
VS.NET (nee VS7) will ship with VC++, including updates to the venerable MFC and the ATL, in addition to the .NET components (C#, VB.NET, Jscript, the Execution Engine, Common Language Runtime, the Base Class Library, Winforms, Web UI, ASP.NET, etc). The shipping MS language tools share the same IDE. I expect CVF 7 to plug into that IDE in a similar fashion to the way it plugs into VS 6 today.
The future of mixed language programming in VS.NET will be a bit different.
The easy mixed language story in .NET is when the languages are all .NET compatible - going from managed code in lang A to managed code in lang B. This is guaranteed to be a breeze by the .NET Common Language Runtime and the Common Language Specification. There have been some 20 or so languages announced, including C#, VB.NET, JScript, Cobol, Eifel, APL, PASCAL, CAML, Perl, Python...
VC++ 7 will be the only MS language tool capable of producing unmanaged code. I expect the mixed language story from unmanaged VC++ to unmanaged VF to be pretty much the same story it is today - the ide makes life very easy : get the runtime library settings correct and static linking is as easy as pressing the Build button. Also, the DLL interop story for these two will be much the same.
As for VF dealing with mixed language programming with .NET "managed code", there lies the new frontier. First, I don't expect VF to be targeting .NET's managed execution environment. I'm sure that the disadvantages for typical Fortran applications that Steve mentions refers to the cost wrt execution speed. I can remember reading an article about the .NET Technology Preview where the author (Richter maybe?) saw an initial cost of 25% in C++ code but expected that to reduce to 10-15% by shipping date (I can't seem to locate the article for reference). There's further expectation of improvement down the road. But the implication is that there's likely a slightly larger cost to Fortran code (than compared to C++). Then there's also a question of demand. While IMO it'd be nice for various reasons to have an Fortan'.Net, I think there is a real question of demand in the Fortran community - a community that I see as slow to adopt newer technologies/methodologies. There's also the question of cost. The language (and therefore the compiler) is certainly impacted - the Common Language Specification requires concepts not currently included in f95 - not the least of which are objects (& related OO constructs), out of band exception handling, and unicode support. In addition, a new code generator would be needed to target MSIL instead of native code. And the runtime library would be greatly affected. So managed code <==> unmanaged code interop will likely be an issue.
Managed code calling unmanaged code is handled in a couple of ways - calling legacy DLLs with Pinvoke (VB's Declare statement on steroids) and calling legacy COM objects with the CLR's Runtime Callable Wrapper. It may also be possible to use managed C++ in 'unsafe mode' to link to legacy code. (legacy in this context refers to unmanaged code.)
For unmanaged code calling managed code, there is the COM callable wrapper which acts as a proxy for the managed object.
So while .NET is not COM based, COM is a heavily leveraged interop facility in dealing with managed and unmanaged code together (although the CCW and RCW are not without their own overhead). Further improveme nts in CVF's COM capabilities would facilitate a richer interop story between unmanaged CVF code and .NET objects.
My group has a current project underway which is designed with .NET and implemented in C#. We make calls out of the runtime to legacy VF DLLs using Pinvoke. The DLL routines in turn make callbacks back to .NET objects through the COM Callable Wrapper and CVF Module Wizard generated code. I can vouch for this working today with VS.NET beta 1 and CVF 6.5.
hth,
John
The future of mixed language programming in VS.NET will be a bit different.
The easy mixed language story in .NET is when the languages are all .NET compatible - going from managed code in lang A to managed code in lang B. This is guaranteed to be a breeze by the .NET Common Language Runtime and the Common Language Specification. There have been some 20 or so languages announced, including C#, VB.NET, JScript, Cobol, Eifel, APL, PASCAL, CAML, Perl, Python...
VC++ 7 will be the only MS language tool capable of producing unmanaged code. I expect the mixed language story from unmanaged VC++ to unmanaged VF to be pretty much the same story it is today - the ide makes life very easy : get the runtime library settings correct and static linking is as easy as pressing the Build button. Also, the DLL interop story for these two will be much the same.
As for VF dealing with mixed language programming with .NET "managed code", there lies the new frontier. First, I don't expect VF to be targeting .NET's managed execution environment. I'm sure that the disadvantages for typical Fortran applications that Steve mentions refers to the cost wrt execution speed. I can remember reading an article about the .NET Technology Preview where the author (Richter maybe?) saw an initial cost of 25% in C++ code but expected that to reduce to 10-15% by shipping date (I can't seem to locate the article for reference). There's further expectation of improvement down the road. But the implication is that there's likely a slightly larger cost to Fortran code (than compared to C++). Then there's also a question of demand. While IMO it'd be nice for various reasons to have an Fortan'.Net, I think there is a real question of demand in the Fortran community - a community that I see as slow to adopt newer technologies/methodologies. There's also the question of cost. The language (and therefore the compiler) is certainly impacted - the Common Language Specification requires concepts not currently included in f95 - not the least of which are objects (& related OO constructs), out of band exception handling, and unicode support. In addition, a new code generator would be needed to target MSIL instead of native code. And the runtime library would be greatly affected. So managed code <==> unmanaged code interop will likely be an issue.
Managed code calling unmanaged code is handled in a couple of ways - calling legacy DLLs with Pinvoke (VB's Declare statement on steroids) and calling legacy COM objects with the CLR's Runtime Callable Wrapper. It may also be possible to use managed C++ in 'unsafe mode' to link to legacy code. (legacy in this context refers to unmanaged code.)
For unmanaged code calling managed code, there is the COM callable wrapper which acts as a proxy for the managed object.
So while .NET is not COM based, COM is a heavily leveraged interop facility in dealing with managed and unmanaged code together (although the CCW and RCW are not without their own overhead). Further improveme nts in CVF's COM capabilities would facilitate a richer interop story between unmanaged CVF code and .NET objects.
My group has a current project underway which is designed with .NET and implemented in C#. We make calls out of the runtime to legacy VF DLLs using Pinvoke. The DLL routines in turn make callbacks back to .NET objects through the COM Callable Wrapper and CVF Module Wizard generated code. I can vouch for this working today with VS.NET beta 1 and CVF 6.5.
hth,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I take it from John's post that C++ and CVF are unmanaged languages. What's the definition of a managed language?
Does anyone know what Microsoft's estimate of the release of .NET is?
Can anyone suggest a good reference for what .NET is and how it will work?
Mike Durisin
Does anyone know what Microsoft's estimate of the release of .NET is?
Can anyone suggest a good reference for what .NET is and how it will work?
Mike Durisin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mike,
VC++ 7 can target both managed code and unmanaged (native) code. I'm only making a SWAG when I say that CVF 7 will only target unmanaged (native) code.
Managed code is code that targets the Common Language Runtime and that produces MSIL (Microsoft Intermediate Language) instead of native (platform specific) object code. Really, you can think of it as a virtual machine ala the Java virtual machine - although MS would never call it that. They prefer the term 'execution engine'. I can't imagine why?! ;-)
There is no public release date yet. VS beta 2 should be out somewhat soon (June?). There's a tremendous amount of documentation available today. A good starting place is http://msdn.microsoft.com/net/. Also the MSDN Magazine (available online at http://msdn.microsoft.com/msdnmag/) has technical articles on .NET start as early as 09/2000. Richter's article in the 9/2000 issue is a good starting point too.
hth,
John
VC++ 7 can target both managed code and unmanaged (native) code. I'm only making a SWAG when I say that CVF 7 will only target unmanaged (native) code.
Managed code is code that targets the Common Language Runtime and that produces MSIL (Microsoft Intermediate Language) instead of native (platform specific) object code. Really, you can think of it as a virtual machine ala the Java virtual machine - although MS would never call it that. They prefer the term 'execution engine'. I can't imagine why?! ;-)
There is no public release date yet. VS beta 2 should be out somewhat soon (June?). There's a tremendous amount of documentation available today. A good starting place is http://msdn.microsoft.com/net/. Also the MSDN Magazine (available online at http://msdn.microsoft.com/msdnmag/) has technical articles on .NET start as early as 09/2000. Richter's article in the 9/2000 issue is a good starting point too.
hth,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm far from an expert on .NET, nor on Visual Basic. The book on VB.NET based on the public beta version, published by WROX, is quite readable. If you don't care about VB but prefare C/C++/C#, there is a similar book about C#.NET by WROX. Both of these also discuss .NET to some extent.
According to the book on VB.NET, all languages that use translation to the intermediate "byte code" will have more or less the same performance. The interesting thing is how good this performance is, compared to what can be achieved by e.g. a future Visual Fortran.NET which does not use this "byte code". Another participant in this thread indicate that C++ (which supposedly avoids this "byte code") will be 25% faster than the true .NET compilers, but that this advantage may be reduced to 10-15%. In my view, this would then not be a big difference. How will VF.NET be able to fare, compared to this?
Another aspect is this: Will there be available numerical libraries (NAG, IMSL, etc.) for e.g. VB.NET, and if so, how does these libraries compare speed-wise to what can be achieved with Visual Fortran.NET?
Some important news in .NET are:
* common development environment (editor, debugger, GUI builder, etc.) for all languages, using Visual Studio.NET.
* relatively simple to integrate routines from several languages.
* COM will disappear, together with the Registry. Some XML files are supposed to give the same service. This is a huge advantage for deployment: we are back to the process where it suffices to copy .exe files (+ xml files) to the desired directory.
* In a transitional periode, there will be some way to handle COM based code.
What is the role of VF in this?
* enable the continuous use of old Fortran-based code.
* depending on the speed penalty of "byte code" based languages, enable to make efficient routines.
* a language for those who wants to use a well known language
One problem with integrating VF in .NET is (as someone already said) that Fortran is not object oriented (at present). This is also an advantage, in the sense that it is somewhat easier to learn.
What then if VF becomes totally integrated in .NET, including the generation of "byte code"? What are the consequences of this?
Since that most likely will remove the speed advantage of Fortran, the result will be that Fortran will be used for:
* handling old Fortran code
* development by those who do not want to learn a new language
The same may be the consequence if someone delivers a high quality numeric library for .NET, at least if this is efficient.
To conclude: This is what I'd like to see by a VF integrated with .NET:
* Easy to integrate Fortran code with other languages (simpler than today!!).
* Production of efficient code, even if this breaks the idea of "byte code".
* Easy deployment of produced code - avoiding registration by use of xml files, in a true .NET style. (I don't know how this can be done.)
* A decent tutorial on how to use VF. The problem with the present documentation is that you have to be some sort of Visual Studio/COM guru to understand the documentation, and at the same time, one argument for using Fortran is that you don't have to learn COM, etc. (I'm sure several of us would volunteer to dissect a tutorial in prepraration...)
-Bernt Lie
According to the book on VB.NET, all languages that use translation to the intermediate "byte code" will have more or less the same performance. The interesting thing is how good this performance is, compared to what can be achieved by e.g. a future Visual Fortran.NET which does not use this "byte code". Another participant in this thread indicate that C++ (which supposedly avoids this "byte code") will be 25% faster than the true .NET compilers, but that this advantage may be reduced to 10-15%. In my view, this would then not be a big difference. How will VF.NET be able to fare, compared to this?
Another aspect is this: Will there be available numerical libraries (NAG, IMSL, etc.) for e.g. VB.NET, and if so, how does these libraries compare speed-wise to what can be achieved with Visual Fortran.NET?
Some important news in .NET are:
* common development environment (editor, debugger, GUI builder, etc.) for all languages, using Visual Studio.NET.
* relatively simple to integrate routines from several languages.
* COM will disappear, together with the Registry. Some XML files are supposed to give the same service. This is a huge advantage for deployment: we are back to the process where it suffices to copy .exe files (+ xml files) to the desired directory.
* In a transitional periode, there will be some way to handle COM based code.
What is the role of VF in this?
* enable the continuous use of old Fortran-based code.
* depending on the speed penalty of "byte code" based languages, enable to make efficient routines.
* a language for those who wants to use a well known language
One problem with integrating VF in .NET is (as someone already said) that Fortran is not object oriented (at present). This is also an advantage, in the sense that it is somewhat easier to learn.
What then if VF becomes totally integrated in .NET, including the generation of "byte code"? What are the consequences of this?
Since that most likely will remove the speed advantage of Fortran, the result will be that Fortran will be used for:
* handling old Fortran code
* development by those who do not want to learn a new language
The same may be the consequence if someone delivers a high quality numeric library for .NET, at least if this is efficient.
To conclude: This is what I'd like to see by a VF integrated with .NET:
* Easy to integrate Fortran code with other languages (simpler than today!!).
* Production of efficient code, even if this breaks the idea of "byte code".
* Easy deployment of produced code - avoiding registration by use of xml files, in a true .NET style. (I don't know how this can be done.)
* A decent tutorial on how to use VF. The problem with the present documentation is that you have to be some sort of Visual Studio/COM guru to understand the documentation, and at the same time, one argument for using Fortran is that you don't have to learn COM, etc. (I'm sure several of us would volunteer to dissect a tutorial in prepraration...)
-Bernt Lie
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some further comments...
The .NET Framework is all about the CLR. CLS compliant languages (those that target the CLR) are considered equal in the eyes of the CLR. For example, that is a big reason why C# does not currently support the equivalent of C++ templates despite the popularity and utility of this C++ feature - MS wants to develop generic programming capability inside the CLR so that all CLS languages can benefit. Another interesting application of this strategy has to do with compiler optimizations. The MS implementations so far have shied away from doing much in the way of optimizations going from CLS compliant language to MSIL. They've stated that by leaving the optimizations to the MSIL to native code step (JIT compilation or install time compilation) allows all CLS compliant implementations to benefit from the same optimizations. A down side is that this takes the optimizations out of the hands of the language specific compiler teams (who may have a great deal of experience optimizing their implementations) and puts it squarely in the hands of the MS MSIL/JIT compiler writers.
I haven't heard about any .NET (managed code) numeric libraries. And btw, I'd be surprised if VF 7 adopted the moniker VF.NET.
Other comments:
Some important news in .NET are:
common development environment (editor, debugger, GUI builder, etc.) for all languages, using Visual Studio.NET.
News for Visual Studio (broader suite of integrated tools), but not really .NET news.
This confusion of what exactly is .NET can be blamed on MS's marketing group and their branding of all things as .NET. They did the same darn thing with ActiveX.
relatively simple to integrate routines from several languages.
Yes, between CLS compliant languages.
COM will disappear, together with the Registry. Some XML files are supposed to give the same service. This is a huge advantage for >deployment: we are back to the process where it suffices to copy .exe files (+ xml files) to the desired directory.
NO. COM does not disappear. .NET is not based on COM, but "Virtually all aspects of the COM programming model have survived (interfaces, classes, attributes, context, and so on)." 12/2000 MSDN Don Box column quote. In addition, as previously mentioned, COM is a key to legacy (unmanaged code) interop in .NET.
What is the role of VF in this?
My guess is that VF's role will be virtually unchanged from today. High performance native code, with a good Win32 support.
What then if VF becomes totally integrated in .NET, including the generation of "byte code"? What are the consequences of this?
I doubt this will be of immediate concern. I believe that there are benefits for Fortran users in a .NET variant, but the business case will be made when it is thought that there are enough users out there to support the effort required for this.
To conclude: This is what I'd like to see by a VF integrated with .NET:
Easy to integrate Fortran code with other languages (simpler than today!!).
I believe it will be much like today.
Production of efficient code, even if this breaks the idea of "byte code".
Yep. Efficient native code is a strength of CVF.
Easy deployment of produced code - avoiding registration by use of xml files, in a true .NET style. (I don't know how this can be done.)
I believe it will be much like today. Of course, CVF programmers are welcome to incorporate the use of XML configuration files for their applications rather than storing application/user specific configuration in the registry.
The .NET Framework is all about the CLR. CLS compliant languages (those that target the CLR) are considered equal in the eyes of the CLR. For example, that is a big reason why C# does not currently support the equivalent of C++ templates despite the popularity and utility of this C++ feature - MS wants to develop generic programming capability inside the CLR so that all CLS languages can benefit. Another interesting application of this strategy has to do with compiler optimizations. The MS implementations so far have shied away from doing much in the way of optimizations going from CLS compliant language to MSIL. They've stated that by leaving the optimizations to the MSIL to native code step (JIT compilation or install time compilation) allows all CLS compliant implementations to benefit from the same optimizations. A down side is that this takes the optimizations out of the hands of the language specific compiler teams (who may have a great deal of experience optimizing their implementations) and puts it squarely in the hands of the MS MSIL/JIT compiler writers.
I haven't heard about any .NET (managed code) numeric libraries. And btw, I'd be surprised if VF 7 adopted the moniker VF.NET.
Other comments:
Some important news in .NET are:
common development environment (editor, debugger, GUI builder, etc.) for all languages, using Visual Studio.NET.
News for Visual Studio (broader suite of integrated tools), but not really .NET news.
This confusion of what exactly is .NET can be blamed on MS's marketing group and their branding of all things as .NET. They did the same darn thing with ActiveX.
relatively simple to integrate routines from several languages.
Yes, between CLS compliant languages.
COM will disappear, together with the Registry. Some XML files are supposed to give the same service. This is a huge advantage for >deployment: we are back to the process where it suffices to copy .exe files (+ xml files) to the desired directory.
NO. COM does not disappear. .NET is not based on COM, but "Virtually all aspects of the COM programming model have survived (interfaces, classes, attributes, context, and so on)." 12/2000 MSDN Don Box column quote. In addition, as previously mentioned, COM is a key to legacy (unmanaged code) interop in .NET.
What is the role of VF in this?
My guess is that VF's role will be virtually unchanged from today. High performance native code, with a good Win32 support.
What then if VF becomes totally integrated in .NET, including the generation of "byte code"? What are the consequences of this?
I doubt this will be of immediate concern. I believe that there are benefits for Fortran users in a .NET variant, but the business case will be made when it is thought that there are enough users out there to support the effort required for this.
To conclude: This is what I'd like to see by a VF integrated with .NET:
Easy to integrate Fortran code with other languages (simpler than today!!).
I believe it will be much like today.
Production of efficient code, even if this breaks the idea of "byte code".
Yep. Efficient native code is a strength of CVF.
Easy deployment of produced code - avoiding registration by use of xml files, in a true .NET style. (I don't know how this can be done.)
I believe it will be much like today. Of course, CVF programmers are welcome to incorporate the use of XML configuration files for their applications rather than storing application/user specific configuration in the registry.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page