topic Re: Future of ARX/DBX in ObjectARX Forum

Future of ARX/DBX

Anonymous — Tue, 19 Oct 2004 17:54:22 GMT

When Autodesk plans full support for .NET architecture in ARX. We want to begin working on a very big project and I don't want to conceal that we wouild love to do it in C#. Unfortunately, only a part of ARX library is available in .NET wrapers (eg. we can't create custom entites). Hence, we are in a difficult situation. We could do one part of a project in C++ and another part in C#. Yet, we are affraid that soon all code will be re-writen to managed code and in the next versions of ARX/DBX unmanaged code will not be supported. It means we will have to rewrite a big part of our code yet again. If we could get at least an approximate time of the introduction of the possibility of creating custom entites in managed code we could calculate what suits us best when it comes to time and money. Regards Kuba Szostak

Re: Future of ARX/DBX

Anonymous — Tue, 19 Oct 2004 18:41:05 GMT

We have been told by Autodesk that unmanaged code will always be supported. There is way too much code out there for Autodesk to all of a sudden say "sorry, you have to completely re-write it to managed code". For us, I would just have to close my doors, because it would take years to recode our products.

Re: Future of ARX/DBX

Anonymous — Tue, 19 Oct 2004 19:01:11 GMT

Good topic to discuss. What I have a problem is Microsoft has pretty much told every one that MFC will be supported but not enhanced on pace with Dot Net. I have lot of our legacy code which is written using DAO. DAO will deprecated in the next version of MFC. I would love to use the new Data Access classes from Dot Net. But now Iam stuck. Iam resigned to the fate of rewriting our arx code to DotNEt, which I believe is a waste of Time and Money. "Randy Sanders" wrote in message news:41755fc5_1@newsprd01... > We have been told by Autodesk that unmanaged code will always be supported. > There is way too much code out there for Autodesk to all of a sudden say > "sorry, you have to completely re-write it to managed code". For us, I would > just have to close my doors, because it would take years to recode our > products. > >

Re: Future of ARX/DBX

Anonymous — Tue, 19 Oct 2004 19:51:56 GMT

I don't think managed code will ever replace unmanaged code completely. It is simply not fast or powerful enough. Sure parts of Autocad and many extensions will be in managed code, but the idea that unmanaged code will ever completely go away is, well, silly. That will probably happen the same day the windows kernel is written in dotNET. The program I am writing is already almost too slow in it's fully optimized release build (C++). Managed code works great find if you just want to draw pretty vector graphics or something light, but if you are talking hardcore calculations like rendering or advanced modeling, there is simply no choice but C++ and assembly. There is a very good reason C++ has been around so long. And it's not going anywhere. However, as I understand it, the folks inside AutoDESK are already working on giving .NET almost all the abilities of native extensions. (Custom entities, etc) However, you probably won't ever have the functionality you could get with C++ simply because some things are accomplished through MFC and windows API programming. -Andrew

Re: Future of ARX/DBX

Anonymous — Tue, 19 Oct 2004 20:42:42 GMT

Couple of things I would like to point out. Microsoft is pretty much taking MFC irrelevant. Future versions of windows will have sdk and managed code enhancments only.. If Iam using an arx program and Iam trying to connect to mutitude of databases or web service then it gets really ugly. Plus in this distributed environment tools are required to work out of offsite drawings. Except for Windows Kernel most of the windows are developed using managed code. cheers. -jay "Andrew C" wrote in message news:417570d6$1_2@newsprd01... > I don't think managed code will ever replace unmanaged code completely. It > is simply not fast or powerful enough. Sure parts of Autocad and many > extensions will be in managed code, but the idea that unmanaged code will > ever completely go away is, well, silly. That will probably happen the same > day the windows kernel is written in dotNET. > > The program I am writing is already almost too slow in it's fully optimized > release build (C++). Managed code works great find if you just want to draw > pretty vector graphics or something light, but if you are talking hardcore > calculations like rendering or advanced modeling, there is simply no choice > but C++ and assembly. > > There is a very good reason C++ has been around so long. And it's not going > anywhere. > > However, as I understand it, the folks inside AutoDESK are already working > on giving .NET almost all the abilities of native extensions. (Custom > entities, etc) However, you probably won't ever have the functionality you > could get with C++ simply because some things are accomplished through MFC > and windows API programming. > > -Andrew > >

Re: Future of ARX/DBX

Anonymous — Tue, 19 Oct 2004 20:44:08 GMT

You can write your own managaed 'wrappers' for existing unmanaged code, and continue to access legacy code that way. For UI work, MFC was never something I savored. -- http://www.caddzone.com AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005 http://www.acadxtabs.com "Jay" wrote in message news:41756478$1_1@newsprd01... > Good topic to discuss. > > What I have a problem is Microsoft has pretty much told every one that MFC > will be supported but not enhanced on pace with Dot Net. > I have lot of our legacy code which is written using DAO. DAO will > deprecated in the next version of MFC. I would love to use the new Data > Access classes from Dot Net. But now Iam stuck. > > Iam resigned to the fate of rewriting our arx code to DotNEt, which I > believe is a waste of Time and Money. > > > > "Randy Sanders" wrote in message > news:41755fc5_1@newsprd01... >> We have been told by Autodesk that unmanaged code will always be > supported. >> There is way too much code out there for Autodesk to all of a sudden say >> "sorry, you have to completely re-write it to managed code". For us, I > would >> just have to close my doors, because it would take years to recode our >> products. >> >> > >

Re: Future of ARX/DBX

Anonymous — Tue, 19 Oct 2004 21:33:20 GMT

I don't want this to degenerate into an off-topic discussion about what Microsoft is doing, but I'll say this and will then stop posting to this thread... MFC in my opinion is a multi-faceted dinosaur. It has uses to be sure, but I don't blame Microsoft for letting it go. I only use it as a convenient wrapper around the Win32 API functions. I for one won't miss it. .NET is pretty cool, but I don't think it will replace all programming. For example, sometimes you have no choice but to go to assembly or write your own memory management C library (both of which AutoCAD does in spades I'm sure). DirectX will probably never be managed code, for instance. Just because MFC depreciates and Microsoft concentrates on .NET does not mean the whole native code world is coming to an end. Finally Microsoft is leaving something for other people to do, even if their "managed code" concept is a rip-off of Sun's Java. If Microsoft stops letting native code run, Linux will suddenly be _very_ popular. If DAO goes away you won't be the only one left behind. And I'm sure someone will pick up the slack and write a 3rd-party DAO-compatible library. We live in a capitalist economy that nobody rules. Not even Microsoft. For now, just use your "depreciated" API and relax. Anyway, this is getting too off topic. -Andrew

Re: Future of ARX/DBX

Anonymous — Wed, 20 Oct 2004 14:30:34 GMT

There usually isn't a pressing need to rewrite lots of existing C++ code into C#; as you said that would be a waste. However, switching to managed code (and C#) can be a good excuse to do lot of other cleanup at the same time. The Managed C++ extensions make it relatively straight-forward to expose existing C++ code to the managed world; most existing C APIs (e.g., Win32) can be consumed as-is through P/Invoke. MC++ also makes it possible to consume managed code from unmanaged code; so you could replace your use of DAO with ADO.NET while still using MFC (in theory - I haven't tried this in particular). The new C++/CLI language in Visual Studio 2005 promises to make interoperability between the managed and unmanged worlds even easier. Dan "Jay" wrote in message news:41756478$1_1@newsprd01... > Good topic to discuss. > > What I have a problem is Microsoft has pretty much told every one that MFC > will be supported but not enhanced on pace with Dot Net. > I have lot of our legacy code which is written using DAO. DAO will > deprecated in the next version of MFC. I would love to use the new Data > Access classes from Dot Net. But now Iam stuck. > > Iam resigned to the fate of rewriting our arx code to DotNEt, which I > believe is a waste of Time and Money. > > > > "Randy Sanders" wrote in message > news:41755fc5_1@newsprd01... >> We have been told by Autodesk that unmanaged code will always be > supported. >> There is way too much code out there for Autodesk to all of a sudden say >> "sorry, you have to completely re-write it to managed code". For us, I > would >> just have to close my doors, because it would take years to recode our >> products. >> >> > >

Re: Future of ARX/DBX

Anonymous — Wed, 20 Oct 2004 14:55:22 GMT

Your point well taken. What you say is very appropriate for Graphic intensive applications. But for Database oriented application programs, this poses major road blocks. All our non cad applications have received significant boost going into DotNet. "Andrew C" wrote in message news:41758898_2@newsprd01... > I don't want this to degenerate into an off-topic discussion about what > Microsoft is doing, but I'll say this and will then stop posting to this > thread... > > MFC in my opinion is a multi-faceted dinosaur. It has uses to be sure, but I > don't blame Microsoft for letting it go. I only use it as a convenient > wrapper around the Win32 API functions. I for one won't miss it. > > .NET is pretty cool, but I don't think it will replace all programming. For > example, sometimes you have no choice but to go to assembly or write your > own memory management C library (both of which AutoCAD does in spades I'm > sure). DirectX will probably never be managed code, for instance. > > Just because MFC depreciates and Microsoft concentrates on .NET does not > mean the whole native code world is coming to an end. Finally Microsoft is > leaving something for other people to do, even if their "managed code" > concept is a rip-off of Sun's Java. If Microsoft stops letting native code > run, Linux will suddenly be _very_ popular. > > If DAO goes away you won't be the only one left behind. And I'm sure someone > will pick up the slack and write a 3rd-party DAO-compatible library. We live > in a capitalist economy that nobody rules. Not even Microsoft. For now, just > use your "depreciated" API and relax. > > Anyway, this is getting too off topic. > > -Andrew > >

Re: Future of ARX/DBX

Anonymous — Wed, 20 Oct 2004 17:39:40 GMT

> Sure parts of Autocad and many > extensions will be in managed code, but the idea that unmanaged code will > ever completely go away is, well, silly. That will probably happen the > same day the windows kernel is written in dotNET. "The next release of the Microsoft Windows operating system, code-named "Longhorn," is an essential milestone for many reasons. It is the first operating system built with managed code (...)". http://msdn.microsoft.com/longhorn/default.aspx?pull=/msdnmag/issues/04/01/DevelopingAppsforLonghorn/default.aspx

Re: Future of ARX/DBX

Anonymous — Wed, 20 Oct 2004 20:06:38 GMT

A "Kernel" is not the same thing as an "Operating System". An operating system HAS a kernel, just like it has a bootstrapper and a file system. Although this does bring up a good question of will there be signifigant complications running AutoCAD and our arx applications on the next version of windows.... "Kuba Szostak" wrote in message news:opsf6jceqdriwsw6@geosoft... > > Sure parts of Autocad and many > > extensions will be in managed code, but the idea that unmanaged code will > > ever completely go away is, well, silly. That will probably happen the > > same day the windows kernel is written in dotNET. > > "The next release of the Microsoft Windows operating system, code-named > "Longhorn," is an essential milestone for many reasons. It is the first > operating system built with managed code (...)". > http://msdn.microsoft.com/longhorn/default.aspx?pull=/msdnmag/issues/04/01/DevelopingAppsforLonghorn/default.aspx

Re: Future of ARX/DBX

Anonymous — Thu, 21 Oct 2004 14:07:08 GMT

There are some specially designed benchmarks which show that JIT'd (.NET) code is faster than "native" code. (Sorry, I don't have the reference handy). The basic idea is that each new series of a CPU (x386, original Pentium, P4, etc.) has additional instructions to futher optimize certain situations. If you ship "native" code that targets a generic Pentium, that code won't be able to take advantage of new instructions that are only available on a P4. However, the JITer can carefully examine which CPU it is running on, and use that knowledge to create faster native code from the MSIL. As CPUs get faster, and memory gets cheaper, some things that currently have to be done in native code might move into .NET. Human perception and reaction time isn't changing; if future hardware can execute 1000 instructions to draw a line in the same time that it takes to excute 100 instructions today, then things like DirectX could one day be managed. But as I said in another post, there's generally little pressing need to rewrite exsiting working code into .NET. I suspect that, more than anything else (long term), will keep everything from being in .NET. Dan "Andrew C" wrote in message news:41758898_2@newsprd01... >I don't want this to degenerate into an off-topic discussion about what > Microsoft is doing, but I'll say this and will then stop posting to this > thread... > > MFC in my opinion is a multi-faceted dinosaur. It has uses to be sure, but > I > don't blame Microsoft for letting it go. I only use it as a convenient > wrapper around the Win32 API functions. I for one won't miss it. > > .NET is pretty cool, but I don't think it will replace all programming. > For > example, sometimes you have no choice but to go to assembly or write your > own memory management C library (both of which AutoCAD does in spades I'm > sure). DirectX will probably never be managed code, for instance. > > Just because MFC depreciates and Microsoft concentrates on .NET does not > mean the whole native code world is coming to an end. Finally Microsoft is > leaving something for other people to do, even if their "managed code" > concept is a rip-off of Sun's Java. If Microsoft stops letting native code > run, Linux will suddenly be _very_ popular. > > If DAO goes away you won't be the only one left behind. And I'm sure > someone > will pick up the slack and write a 3rd-party DAO-compatible library. We > live > in a capitalist economy that nobody rules. Not even Microsoft. For now, > just > use your "depreciated" API and relax. > > Anyway, this is getting too off topic. > > -Andrew > >

Re: Future of ARX/DBX

Anonymous — Thu, 21 Oct 2004 19:51:23 GMT

Thanks for all comments. But somebody from Autodesk can tell us when we can implement custome entites in .NET? I know that is hard to say, but even an approximate time satisfied us. Regards Kuba Szostak