Thinking of writing a Windows Script IDE
-
Like the subject line says, I've been throwing around the idea of writing a Windows Script IDE. So far all the test code I've written for the debugger part uses ATL, go figure, but I've run into a problem with the UI side. I have considered using MFC for all the UI, since there is so much stuff already written on the subject, and there is tons of code to be had. On the other WTL's offer of a tiny footprint is really tempting, the main deterrence being the lack of all the fancy UI stuff which I would have code myself. I’ve never written any big applications with WTL, and I don’t imagine there are to many yet who have either. So should I disregard my lazy tendencies and whip it up in WTL or stick with good old reliable? Any input would be greatly appreciated. Thanks, -Ben --------- On the topic of code with no error handling -- It's not poor coding, it's "optimistic" ;)
IMO the answer's simple. Reliable == better. If you already know MFC well enough to write the app, use MFC. You can always write little one-off apps in WTL to teach yourself WTL if you like. --Mike-- http://home.inreach.com/mdunn/ #include "buffy_sig"
-
Like the subject line says, I've been throwing around the idea of writing a Windows Script IDE. So far all the test code I've written for the debugger part uses ATL, go figure, but I've run into a problem with the UI side. I have considered using MFC for all the UI, since there is so much stuff already written on the subject, and there is tons of code to be had. On the other WTL's offer of a tiny footprint is really tempting, the main deterrence being the lack of all the fancy UI stuff which I would have code myself. I’ve never written any big applications with WTL, and I don’t imagine there are to many yet who have either. So should I disregard my lazy tendencies and whip it up in WTL or stick with good old reliable? Any input would be greatly appreciated. Thanks, -Ben --------- On the topic of code with no error handling -- It's not poor coding, it's "optimistic" ;)
For once I agree with Michael :^) If MFC works, and you know MFC, and everyone else knows MFC, that's not a BAD thing... I'm kinda fed up with the anti-MFC sentiment going around... people I work with saying "Yes but you should not use MFC in your com object because MFC is so slow, and huge, and it makes your code bigger, and it doesn't support multiple inheritance"... If the COM object's only designed to run on the server, size really doesn't matter, especially running in a HUGE application like IIS, having a small size wont even keep your app in the CPU cache longer. Now I'm not saying I like to write COM objects with MFC, ATL is much better at that, and it's use of multiple inheritance is much cleaner than MFC's approach. But all of my Server side COM Objects are written in ATL and include MFC support so I can leverage HUGE code bases against them. That's another plus, if someone has already debugged a section of code, why write it over and debug it again? You could more wisely spend that time coming up with a better overall design, or even by going home early and hanging out with your girl. As far as speed goes... People who spend so much time trying to wring out every last instruction cycle, often miss the big picture. The average text parsing code I see written in MFC using CString is so slow I could write faster code in quickbasic. On the other hand, If you know what you're doing (and more importantly what CString is doing), you can use MFC and some CString functionality and write something that would be hard to beat in assembler... At any rate, Don't fear MFC. For what it's worth, if I was writing an application that was an activex control that was going to be redistributed, and was designed to run in a browser through some sort of autoload and autodownload technology, I'd prolly use ATL and WTL. But for any other case, I'd use MFC for application logic, ATL for COM interfaces, #import for calling other COM objects, and I roll my own for accessing databases. so... please help stomp out this Im-So-Macho-Id-Never-Stoop-To-mfc thingy. Dan K
-
For once I agree with Michael :^) If MFC works, and you know MFC, and everyone else knows MFC, that's not a BAD thing... I'm kinda fed up with the anti-MFC sentiment going around... people I work with saying "Yes but you should not use MFC in your com object because MFC is so slow, and huge, and it makes your code bigger, and it doesn't support multiple inheritance"... If the COM object's only designed to run on the server, size really doesn't matter, especially running in a HUGE application like IIS, having a small size wont even keep your app in the CPU cache longer. Now I'm not saying I like to write COM objects with MFC, ATL is much better at that, and it's use of multiple inheritance is much cleaner than MFC's approach. But all of my Server side COM Objects are written in ATL and include MFC support so I can leverage HUGE code bases against them. That's another plus, if someone has already debugged a section of code, why write it over and debug it again? You could more wisely spend that time coming up with a better overall design, or even by going home early and hanging out with your girl. As far as speed goes... People who spend so much time trying to wring out every last instruction cycle, often miss the big picture. The average text parsing code I see written in MFC using CString is so slow I could write faster code in quickbasic. On the other hand, If you know what you're doing (and more importantly what CString is doing), you can use MFC and some CString functionality and write something that would be hard to beat in assembler... At any rate, Don't fear MFC. For what it's worth, if I was writing an application that was an activex control that was going to be redistributed, and was designed to run in a browser through some sort of autoload and autodownload technology, I'd prolly use ATL and WTL. But for any other case, I'd use MFC for application logic, ATL for COM interfaces, #import for calling other COM objects, and I roll my own for accessing databases. so... please help stomp out this Im-So-Macho-Id-Never-Stoop-To-mfc thingy. Dan K
I agree with you to a point. However, if you're talking a server, with lots of connnections. You don't want 1000 instances of your 2 megabyte COM object going, rather you'd have 1000 instances of your 42k COM object.
-
For once I agree with Michael :^) If MFC works, and you know MFC, and everyone else knows MFC, that's not a BAD thing... I'm kinda fed up with the anti-MFC sentiment going around... people I work with saying "Yes but you should not use MFC in your com object because MFC is so slow, and huge, and it makes your code bigger, and it doesn't support multiple inheritance"... If the COM object's only designed to run on the server, size really doesn't matter, especially running in a HUGE application like IIS, having a small size wont even keep your app in the CPU cache longer. Now I'm not saying I like to write COM objects with MFC, ATL is much better at that, and it's use of multiple inheritance is much cleaner than MFC's approach. But all of my Server side COM Objects are written in ATL and include MFC support so I can leverage HUGE code bases against them. That's another plus, if someone has already debugged a section of code, why write it over and debug it again? You could more wisely spend that time coming up with a better overall design, or even by going home early and hanging out with your girl. As far as speed goes... People who spend so much time trying to wring out every last instruction cycle, often miss the big picture. The average text parsing code I see written in MFC using CString is so slow I could write faster code in quickbasic. On the other hand, If you know what you're doing (and more importantly what CString is doing), you can use MFC and some CString functionality and write something that would be hard to beat in assembler... At any rate, Don't fear MFC. For what it's worth, if I was writing an application that was an activex control that was going to be redistributed, and was designed to run in a browser through some sort of autoload and autodownload technology, I'd prolly use ATL and WTL. But for any other case, I'd use MFC for application logic, ATL for COM interfaces, #import for calling other COM objects, and I roll my own for accessing databases. so... please help stomp out this Im-So-Macho-Id-Never-Stoop-To-mfc thingy. Dan K
For those who say MFC/COM/Windows is slow, Just port your code to Java/J2EE/Application Server and then see the reality. X| :mad: :eek: :) ;) ;P :-D :cool: Farhan Noor Qureshi
-
For once I agree with Michael :^) If MFC works, and you know MFC, and everyone else knows MFC, that's not a BAD thing... I'm kinda fed up with the anti-MFC sentiment going around... people I work with saying "Yes but you should not use MFC in your com object because MFC is so slow, and huge, and it makes your code bigger, and it doesn't support multiple inheritance"... If the COM object's only designed to run on the server, size really doesn't matter, especially running in a HUGE application like IIS, having a small size wont even keep your app in the CPU cache longer. Now I'm not saying I like to write COM objects with MFC, ATL is much better at that, and it's use of multiple inheritance is much cleaner than MFC's approach. But all of my Server side COM Objects are written in ATL and include MFC support so I can leverage HUGE code bases against them. That's another plus, if someone has already debugged a section of code, why write it over and debug it again? You could more wisely spend that time coming up with a better overall design, or even by going home early and hanging out with your girl. As far as speed goes... People who spend so much time trying to wring out every last instruction cycle, often miss the big picture. The average text parsing code I see written in MFC using CString is so slow I could write faster code in quickbasic. On the other hand, If you know what you're doing (and more importantly what CString is doing), you can use MFC and some CString functionality and write something that would be hard to beat in assembler... At any rate, Don't fear MFC. For what it's worth, if I was writing an application that was an activex control that was going to be redistributed, and was designed to run in a browser through some sort of autoload and autodownload technology, I'd prolly use ATL and WTL. But for any other case, I'd use MFC for application logic, ATL for COM interfaces, #import for calling other COM objects, and I roll my own for accessing databases. so... please help stomp out this Im-So-Macho-Id-Never-Stoop-To-mfc thingy. Dan K
> I'm kinda fed up with the anti-MFC sentiment going around... I by no means meant to come across as implying that I thought MFC sucks, because I don’t. In fact I quite enjoy using it. The reason for the post was simply to get other peoples views on the topic, in case I might have missed something. Truth be told, I had already been leaning towards using MFC for the UI, but would have really liked to hear of peoples experience with WTL in large projects. Have a good one, -Ben --------- On the topic of code with no error handling -- It's not poor coding, it's "optimistic" ;)
-
Like the subject line says, I've been throwing around the idea of writing a Windows Script IDE. So far all the test code I've written for the debugger part uses ATL, go figure, but I've run into a problem with the UI side. I have considered using MFC for all the UI, since there is so much stuff already written on the subject, and there is tons of code to be had. On the other WTL's offer of a tiny footprint is really tempting, the main deterrence being the lack of all the fancy UI stuff which I would have code myself. I’ve never written any big applications with WTL, and I don’t imagine there are to many yet who have either. So should I disregard my lazy tendencies and whip it up in WTL or stick with good old reliable? Any input would be greatly appreciated. Thanks, -Ben --------- On the topic of code with no error handling -- It's not poor coding, it's "optimistic" ;)
This was already talked about a few days ago. http://www.codeproject.com/lounge.asp?select=38356&fr=227&forumid=1159#xx37661xx
-
I agree with you to a point. However, if you're talking a server, with lots of connnections. You don't want 1000 instances of your 2 megabyte COM object going, rather you'd have 1000 instances of your 42k COM object.
While it may be possible (I'm not sure if it is or isn't) to get your .DLL to be re-loaded into memory for every connection, it definetly wouldn't be wise or standard windows programming. Check out the functionality in DllCanUnloadNow, if you're not familiar with it :) Also maybe look at your class factory's reference counting. It's all there to facilitate only having one copy of the binary in memory. Dan K
-
While it may be possible (I'm not sure if it is or isn't) to get your .DLL to be re-loaded into memory for every connection, it definetly wouldn't be wise or standard windows programming. Check out the functionality in DllCanUnloadNow, if you're not familiar with it :) Also maybe look at your class factory's reference counting. It's all there to facilitate only having one copy of the binary in memory. Dan K
The problem is that MFC objects aren't free threaded. If you want any kind of performance, you need each thread to load its own instance of the object.
-
The problem is that MFC objects aren't free threaded. If you want any kind of performance, you need each thread to load its own instance of the object.
Yes, but you can make ATL COM objects and add MFC support, that was what I was suggesting in my original post :) MFC COM support is an afterthought, and it doesn't work well because MFC wasn't designed with COM in mind, in fact COM wasn't even around... That still doesn't stop you from making an ATL project and using MFC support, which is what I prefer to do... I hear alot about how that's such a bad thing 'cause MFC is so slow, and exception handling will make your code slow, and MFC is so large... but in reality, I think that my code made with MFC will take the pepsi challenge vs non MFC code, especially in a highly complex system. Performance is not the only objective when writing code (Something Microsoft seems to miss some times) There's also maintainability, and reliability, both of which are helped considerably by exception handling. Small/simple problem domain projects I would consider using ATL only, but as the project gets more complex, I think it pays to use paradigms that are easier to understand, implement, debug, and profile. Time not spent on implementation and instead spent upfront on design, and later on in profiling and optimization I think has proven to be time better spent. For more on this please read 'Michael Abrash's Graphics Programming Black Book', on which I'm entirely in agreement. The book's somewhat mis-named though, I'd rename it 'Michael Abrash's optimizing Black Book with some graphics programming thrown in'. Gotta get back to work :) Dan K
-
Yes, but you can make ATL COM objects and add MFC support, that was what I was suggesting in my original post :) MFC COM support is an afterthought, and it doesn't work well because MFC wasn't designed with COM in mind, in fact COM wasn't even around... That still doesn't stop you from making an ATL project and using MFC support, which is what I prefer to do... I hear alot about how that's such a bad thing 'cause MFC is so slow, and exception handling will make your code slow, and MFC is so large... but in reality, I think that my code made with MFC will take the pepsi challenge vs non MFC code, especially in a highly complex system. Performance is not the only objective when writing code (Something Microsoft seems to miss some times) There's also maintainability, and reliability, both of which are helped considerably by exception handling. Small/simple problem domain projects I would consider using ATL only, but as the project gets more complex, I think it pays to use paradigms that are easier to understand, implement, debug, and profile. Time not spent on implementation and instead spent upfront on design, and later on in profiling and optimization I think has proven to be time better spent. For more on this please read 'Michael Abrash's Graphics Programming Black Book', on which I'm entirely in agreement. The book's somewhat mis-named though, I'd rename it 'Michael Abrash's optimizing Black Book with some graphics programming thrown in'. Gotta get back to work :) Dan K
Yes its true. There are too many people just talking religiously about MFC vs WTL vs ATL etc... Each technology has got a use, thats why it was invented in the first place. A wise programmer will know what technology to choose for his application, or part of his application. Personally I have used most of the technologies like MFC, ATL, WTL, STL, and even JScript for the same sofware package. They all blend in nicely if used properly. Regarding the MFC issue, well they say it is bloated, slow and large to distribute. Well, I totally agree, however UI applications are, by nature, bloated, slow and large to distribute when compared to their server side counterparts, so MFC is the best suitor. James (2b || !2b)