Survey Results

FirstPrevNext

Re: DLLs are evil Navin6-Jan-03 10:30 Navin 6-Jan-03 10:30  Statically linked code will almost always be faster than dynamically linked code. And you won't have to worry about the versioning conflicts. COM is evil too, btw. Even a broken clock is right twice a day. Re: DLLs are evil Pit M.6-Jan-03 21:57 Pit M. 6-Jan-03 21:57  >>Statically linked code will almost always be faster than dynamically linked code. but not very much >>And you won't have to worry about the versioning conflicts. That's not true. If the DLL has the same name, but a different interface, you will have a conflict. Re: DLLs are evil Navin7-Jan-03 4:05 Navin 7-Jan-03 4:05  Um, you misunderstood, I am not talking about statically linking to a DLL - that can be even worse. I am saying, statically link ALL the code, no DLL at all! Then the only vesioning issue you have to deal with is in the operating system itself. Even a broken clock is right twice a day. Re: DLLs are evil Fei-tian9-Jan-03 7:14 Fei-tian 9-Jan-03 7:14  COM is a good and simple design in the beginning, but COM becomes complex when more and more sepcial cases are encountered. I don't know why MS added so ugly functions to the COM mechanism. So, I only use COM when I would like to add a class from a DLL file. And so that I will not register the COM object. I just use COM to realize "Interface-Style Programming". Re: DLLs are evil Marc Clifton6-Jan-03 11:30 Marc Clifton 6-Jan-03 11:30  The only good use for DLL's that I've found so far are dynamic plug-in components. I agree. One of the reasons DLL's are evil is because some idiots at Microsoft decided to give you the option to create a LIB for the DLL "to make life easier". That completely broke the "component" capability of the DLL, because now all its entry points were associated to the damn lib. If you changed the DLL, you had to recompile all your code that depended on the LIB. Stupid, stupid, stupid. The next reason is that people are stupid. (Oh, I said that already). They would change the interface or the functionality of an entry point instead of providing a new public name. This resulted in lots of code breaking when a DLL was updated. And there are other reasons... Marc Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Re: DLLs are evil Navin7-Jan-03 6:36 Navin 7-Jan-03 6:36  Preach it, brother! One area where I've gotten myself in trouble in the past was when I tried to link to a .LIB for a system DLL. This is *usually* OK.. until I tried to use a 2000-specific function. You can't just do a check, if NT then don't call this.. the program won't even load if it doesn't find that function's entry point. So that required using LoadLibrary to get the 2000-specific function, so I could call it only in 2000 and have NT still fail gracefully. Ah well. Even a broken clock is right twice a day. One voice in the wilderness Gary Wheeler6-Jan-03 3:28 Gary Wheeler 6-Jan-03 3:28  We dynamically link our applications to MFC. Our application runs in a controlled environment (it's an industrial PC doing process control). I know, that's the easy case. I would think that the opposite case of having to handle every Tom, Dick, or Fred version of Windows, along with the corresponding versions of the MFC DLL's, would have even greater problems than just 'DLL hell'. Software Zen: delete this; ATL Libraries? Paul A. Howes6-Jan-03 2:16 Paul A. Howes 6-Jan-03 2:16  I thought the whole purpose of the ATL was that it consists of C++ templates in header files. You have to direct your compiler's include path to the ATL headers so that the "#include" statements work, but there is no library to link against. Am I wrong? -- Paul "I drank... WHAT?" Re: ATL Libraries? Gary Wheeler6-Jan-03 3:12 Gary Wheeler 6-Jan-03 3:12  Depending on how you build your ATL project, it may depend upon ATL.DLL (or ATL70.DLL, if you're using VS.NET). ATL(70).DLL contains some 'static' code for handling object registration. Software Zen: delete this; The question answers itself Michael Dunn5-Jan-03 20:57 Michael Dunn 5-Jan-03 20:57  Chris Maunder posited: Conflicts between different versions of the MFC and ATL libraries can cause headaches. And thus the answer is "statically link to everything". With MFC this adds a couple hundred K, but results in zero install problems or DLL Hell issues. Case in point: I installed dtSearch recently and doing so broke VC 6. Now I can no longer double-click a DSW file to open the workspace. Since this happened immediately after the install, dtSearch put down some DLL that f'ed up VC. This is exactly the sort of thing you avoid entirely by linking statically. [edit]It's not a file extension that got reassociated, VC 6 still runs, it just crashes immediately.[/edit] --Mike-- When 900 years old you reach, look as good you will not. Hmm. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm Re: The question answers itself Uwe Keim5-Jan-03 21:19 Uwe Keim 5-Jan-03 21:19  But your link times raises then. And simply putting the MFC DLLs locally into your application folder solves all problems, too. Even if you use your own libraries which also uses MFC, which would add another 100k if you would link statically. -- - Free Windows-based Web Content Management System: http://www.zeta-software.de/enu/producer/freeware/download.html - Scanned MSDN Mag ad with YOUR name: www.magerquark.de/misc/CodeProject.html - See me: www.magerquark.de Re: The question answers itself Michael Dunn5-Jan-03 21:38 Michael Dunn 5-Jan-03 21:38  Uwe Keim wrote: But your link times raises then. So what? That is not something that affects the running of the app, nor something the end-user knows about, so it's not a valid thing to base a decision on. Uwe Keim wrote: And simply putting the MFC DLLs locally into your application folder solves all problems, too. Except that introduces a new problem, your distribution size grows by 1.77 MB (for the most common DLLs: mfc42, msvcrt, msvcirt, msvcp60) instead of 100K. So you would need to have 17 modules all using MFC to make that a valid argument. --Mike-- When 900 years old you reach, look as good you will not. Hmm. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm Re: The question answers itself #realJSOP6-Jan-03 2:39 #realJSOP 6-Jan-03 2:39  Do you honestly think longer link times are a viable trade-off for overall reliability for the end-user? Furthermore, putting the DLL's in your own folder don't solve squat if the DLL was loaded by another app and that app is still running. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio. ------- signature ends Re: The question answers itself Uwe Keim6-Jan-03 3:07 Uwe Keim 6-Jan-03 3:07  You're all so altruistic, only regarding the end-user. If everyone would think this way, the whole .NET Framework stuff would be unncessary, since it primarly only is something the developer benefits, not the end user (he even needs to download additional 20 MB). -- - Free Windows-based Web Content Management System: http://www.zeta-software.de/enu/producer/freeware/download.html - Scanned MSDN Mag ad with YOUR name: www.magerquark.de/misc/CodeProject.html - See me: www.magerquark.de Re: The question answers itself Navin6-Jan-03 3:54 Navin 6-Jan-03 3:54  It's not just the end user, it's also the developer support time. Nothing sucks worse than trying to debug system DLL versioning poblems. Not all systems have the right MFC versions... and if you try to install your own, you open up a new can of worms... I do wonder if .NET will be better or worse. I suppose if any newer version of .NET is 100% backwards compatible, and there is some mechanism for ensuring that code won't run unless at least version x of the .NET framework exists, then it will be much better. Even a broken clock is right twice a day. Re: The question answers itself Stephane Rodriguez.6-Jan-03 10:13 Stephane Rodriguez. 6-Jan-03 10:13  Navin wrote: I suppose if any newer version of .NET is 100% backwards compatible, and there is some mechanism for ensuring that code won't run unless at least version x of the .NET framework exists, then it will be much better. An associated .config file to the app can rule this, but only if the developer knows how to handle it properly. Most of the time, and that's the default behavior as well, end-users are required to have the same .NET run-time build than the one used by the developer to compile his code against. Which means x can be either very old, or very new compared to the one currently installed on the end-user machine. Potentially sucks. Re: The question answers itself #realJSOP6-Jan-03 3:56 #realJSOP 6-Jan-03 3:56  I don't do .NET... And if you're not working with the end-user in mind, what's the freakin point? ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio. ------- signature ends Re: The question answers itself David Wulff6-Jan-03 6:52 David Wulff 6-Jan-03 6:52  John Simmons / outlaw programmer wrote: I don't do .NET... You make it sound like Heroin. David Wulff http://www.davidwulff.co.uk Re: The question answers itself Roger Jane6-Jan-03 7:39 Roger Jane 6-Jan-03 7:39  I'm defintely on the side of throwing the DLLs to the four winds. More files to install means more problems for the user and the support department, as well as those setting up test environments! I like the idea of a reasonable (ok, smallish) sized application shipping in as few files as possible, preferably one. * Help, something's gone wrong! * What version do they have? Do you want a single answer to the above or any number of combinations of different executables and DLL versions. *climbs off soapbox* Re: The question answers itself Philip Patrick7-Jan-03 2:28 Philip Patrick 7-Jan-03 2:28  John Simmons / outlaw programmer wrote: if the DLL was loaded by another app and that app is still running. Not exactly. If interface of function or class in that DLL has been changed, new application will run a new DLL, and won't use the old one with old interface Philip Patrick Web-site: www.stpworks.com "Two beer or not two beer?" Shakesbeer Re: The question answers itself Navin6-Jan-03 3:05 Navin 6-Jan-03 3:05  Exactly - when I use MFC (which is less and less these days), I always statically link. Unfortunatley, some legacy code around here links dynamically, and can be difficult to change. Especially when some other team owns the code. Even a broken clock is right twice a day. Re: The question answers itself Blake Miller6-Jan-03 4:04 Blake Miller 6-Jan-03 4:04  It is also entirely possible that dtSearch just redirected the shell command for DSW files? I could see someone using DSW to mean 'Dt Search Workfile' or something like that, so of course, trying to double-click on a DSW file results in no activity, or something wierd with dtSearch occuring. One of these dyas, lazy programmers will get of their collective asses and realize Windows has been supporting file extensions longer than 3 characters since Windows 95 C++/MFC/InstallShield since 1993 Re: The question answers itself Roger Jane6-Jan-03 7:42 Roger Jane 6-Jan-03 7:42  I know that, you know that, pretty mucvh everyone here knows that... But does Microsoft realise it? How many current microsoft products still use 3-character extensions and how many strangely call all their internal files by 8.3 names? Do they know somethign we don't perhaps...? Rog Re: The question answers itself Michael Dunn8-Jan-03 15:31 Michael Dunn 8-Jan-03 15:31  No, VC 6 runs (but I did check the registry just to be sure). VC 6 runs, then blows up. --Mike-- I'm bored... Episode I bored. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm Re: The question answers itself Marc Clifton6-Jan-03 11:26 Marc Clifton 6-Jan-03 11:26  Case in point: I installed dtSearch recently and doing so broke VC 6. Now I can no longer double-click a DSW file to open the workspace. This sounds more like the mapping of file extension to application got broken, not a DLL problem. Maybe dtSearch assigned the DSW extension to something else. Marc Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka

Last Visit: 31-Dec-99 18:00     Last Update: 23-Sep-24 11:53 Refresh ᐊ Prev123 Next ᐅ

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.