Important advice for programmers! Please read!!!

[tR1cKy]

I've recently downloaded and installed the Civ3 FLC Editor by Cyber Dreyk. It's after i saw the behaviour of this application that i felt the need of this post.

For Cyber Dreyk: i don't intend to bash on you. I really appreciate your work. The FLC editor is a useful utility. What i strongly despise is the way it installs and (doesn't) uninstalls of a Windoze box. It has an almost viral behaviour. This is the reason why i'm using it an example on how NOT to set up an application.

This utility copies 25 files in the Windoze System folder and creates no less than 47 new folders in the Windoze registry. This is a big, big, big, big NO-NO. Putting stuff in registry and system is a very critical action and must be avoided unless it's really, really essential for your application to work correctly. In fact, this tampering with vital areas of the operating sistem is the main reason why Windoze boxes tend to go FUBAR after a few installing and de-installing of applications.

In this particular case, things are even worse. Files are copied via a batch script, so there is NO CONTROL on what is copied. What if there's already a dll in the System folder with the same name of one of these files? Then, the program doesn't provide an uninstall option. The only way to get rid of all this stuff is to remove the registry keys and the dll in the system folder manually, and then un-registering the dlls via console. Obviosly, these operation must be performed only if you really know what you're doing, or else you'll end up formatting and re-installing your box. This means that, unless you're a very experienced user, you must keep all this crap forever.

Cyber and others, please listen: only few programs have a real need of tampering with the system and/or the registry: video and audio drivers need that, or they won't work. A video codec such as XviD need that, or else it will be unusable by players and editors. A java virtual machine need that, or its environment will be useless. A generic application like those you find here has absolutely no reason to alter in any way the os.

Cyber, you don't need to messing this way with the registry and System. You can have your dlls in the directory where the program is installed and still use them. If you want to register an application, one key in the registry is all you need. ONE, not 47. Use text files (like the ini's) for your configuration and leave the register alone. It's the best thing you can do.

I urge you to release a new version in which you leave off all the unnecessary tampering. And i urge all the developers that have posted their programs here to check what these applications do on the operating system and, if necessary, correct their behaviour.

You don't want your application, on which you've spent countless hours of your free time, to be the cause of a FORMAT C:\ on a gamer's PC, don't you?

Thanks to all for your attention.
tR1cKy

 

[Cyber Dreyk]

I've recently downloaded and installed the Civ3 FLC Editor by Cyber Dreyk. It's after i saw the behaviour of this application that i felt the need of this post.

For Cyber Dreyk: i don't intend to bash on you. I really appreciate your work. The FLC editor is a useful utility. What i strongly despise is the way it installs and (doesn't) uninstalls of a Windoze box. It has an almost viral behaviour. This is the reason why i'm using it an example on how NOT to set up an application.

This utility copies 25 files in the Windoze System folder and creates no less than 47 new folders in the Windoze registry. This is a big, big, big, big NO-NO. Putting stuff in registry and system is a very critical action and must be avoided unless it's really, really essential for your application to work correctly. In fact, this tampering with vital areas of the operating sistem is the main reason why Windoze boxes tend to go FUBAR after a few installing and de-installing of applications.

In this particular case, things are even worse. Files are copied via a batch script, so there is NO CONTROL on what is copied. What if there's already a dll in the System folder with the same name of one of these files? Then, the program doesn't provide an uninstall option. The only way to get rid of all this stuff is to remove the registry keys and the dll in the system folder manually, and then un-registering the dlls via console. Obviosly, these operation must be performed only if you really know what you're doing, or else you'll end up formatting and re-installing your box. This means that, unless you're a very experienced user, you must keep all this crap forever.

tR1cKy, you are a very suspicious man as I can see. Are you a system administrator?
Well, as you know, Civ3FlcEdit & Civ3MM are freeware utilities. So I have not possibility to use Install Shield or Win Installer, also I have not any other installers at my disposal.
Therefore I have used PackageForTheWeb - only one installer which I have. And this utility have not "uninstall" possibility...

Cyber and others, please listen: only few programs have a real need of tampering with the system and/or the registry: video and audio drivers need that, or they won't work. A video codec such as XviD need that, or else it will be unusable by players and editors. A java virtual machine need that, or its environment will be useless. A generic application like those you find here has absolutely no reason to alter in any way the os.

I know it. Solely one reason to make it for my utilities is the following: I want that both utilities uses the same DLL's set and can working even in case user have copyid executable files in any other folder.

Cyber, you don't need to messing this way with the registry and System. You can have your dlls in the directory where the program is installed and still use them. If you want to register an application, one key in the registry is all you need. ONE, not 47. Use text files (like the ini's) for your configuration and leave the register alone. It's the best thing you can do.

My friend, all my utilities using only one registry key: "HKEY_CURRENT_USER\Software\Cyber Dreyk\...". But I have using not only my DLL files and cannot controling they registry keys...

I urge you to release a new version in which you leave off all the unnecessary tampering. And i urge all the developers that have posted their programs here to check what these applications do on the operating system and, if necessary, correct their behaviour.

Well, I can make that next installation will place all DLLs to the same folder as executables. Specially for you!

You don't want your application, on which you've spent countless hours of your free time, to be the cause of a FORMAT C:\ on a gamer's PC, don't you?

Mm-m-m... You are crack me! Your PC will be formatted in 10 seconds!
9!
8!
7!



Thank you for trouble about our security!
And please excuse my stupid humor!

P.S. Wrong forum!

 

[ainwood]

Nicely handled

BTW: Have you tried inno setup?

I use this - and its quite good (freeware)!

 

[Gramphos]

If you want to register an application, one key in the registry is all you need. ONE, not 47. Use text files (like the ini's) for your configuration and leave the register alone. It's the best thing you can do.

Well, Microsoft recommentds the use of the Registry for storing configuration data. INI-files are a leftover from Windows 3.1. Sure, the API to handle them still exists, but in general keeping settings in the registry also have a few benefits. One of them is that you can easy allow for different users on the same computer to use different settings, as well as keep global settings, and installation information in the registry.
Of cource you can spend time on writing your own configuration storage routines, that does all what the registry database does, but using flat files. Still, to have it work on a wide range of OSes you would have to implement it in two ways. For Windows 9x-Me you would have to keep one ini for your app and store userspecific sections in it. For NT-XP you would have to keep global app settings in an ini in the app-folder, and keep user settings in an ini in the My Documents folder of the user.

Also, one main reason why to use the registry to store things is that you can allow users, at uninstall to either keep thei settings or delete them, without leaving many files on the computer. As the registry is a growing only database, would not deleting a small key in it not do mush since it probably only would be left as open space in the registry. However, not deleting the program folders on unistall, to allow the user to save configuration files leaves a lare filestructure on the computer, which is hard for a noram user to navigate through.

In conclution my programs will continue to use between one and three registry keys for storage, and probably load data from more. (Did I mention the the registry is a good way for other aplications to check if and where an apliction is installed?) That is one key for uninstall entry in the Add/Remove control panel, one key with global app info, for itself and depending applictaions, and one key for each user using it for settings.

 

[tR1cKy]

First, thanks to all for seriously considering my concerns.
Second:

My friend, all my utilities using only one registry key: "HKEY_CURRENT_USER\Software\Cyber Dreyk\...". But I have using not only my DLL files and cannot controling they registry keys...

True, but try to expand the key and see the plethora of sub-keys there are in...
To register your apps, you need only 2 subkeys, one for Civ3MM and one for the FLC editor. Not all of them. I'm posting a screenshot on the next post to have you see the mess.

Solely one reason to make it for my utilities is the following: I want that both utilities uses the same DLL's set and can working even in case user have copyid executable files in any other folder.

Laudable, but if you want all your apps use the same DLLs all you need is to install all the executables in the same directory. DLLs can be loaded from the location where a program is started, so no need to bother the System folder.
Also, the copying stuff is useless. Once you register your application in the registry, it is supposed to stay there, and not to be moved around the hard disk. Let's suppose i install your apps in "c:\programs\Cyber Dreyk" - then i move them to "d:\archived stuff\Cyber Dreyk". The problem is that the OS still thinks that the app is located in "c:\programs\Cyber Dreyk" and not elsewhere. In the case you release a patch for the executable, it checks the registry for its location, sees "c:\programs\Cyber Dreyk", goes there and find... nothing. Registered applications are not to be moved.

Well, I can make that next installation will place all DLLs to the same folder as executables. Specially for you!

Thank you! But you're not only doing a favour to me. You're doing a favour to everyone who plans to use your programs

Now let's discuss Gramphos' statements:

Well, Microsoft recommentds the use of the Registry for storing configuration data. INI-files are a leftover from Windows 3.1. Sure, the API to handle them still exists, but in general keeping settings in the registry also have a few benefits. One of them is that you can easy allow for different users on the same computer to use different settings, as well as keep global settings, and installation information in the registry.

Well, micro$oft in the last years has recommended a lot of things. For example, one of them was "keep autoupdate on, so critical patch are delivered automatically to PC's, and the average user doesn't need to worry about it". Many followed this suggestion, only to feel really sorry when a worm managed to infect one of the mirror servers used by MS to deliver windows updates... the result was hundreds of thousands of lusers (yeah, lusers) being infected by a virus took via windoze update... security, we've heard of it

M$ has also recommended all WinXP users to upgrade to service pack 2 ASAP. Again, many did it, only to find later that the firewall built in SP2, and activated by default, interfered with the auto-update feature of their antivirus program, preventing them to obtain an updated virus signature file... security, did we mention that we heard of it?

Gramphos, be wary of what M$ recommends. Often it's not the best thing to do.

For what you say on ini files vs. registry keys, well, i disagree. Keep in mind that "newer" doesn't always mean "better". Actually, sometimes it's just the opposite. INI text files are simple, don't interfere with any part of the OS, can be easily parsed, can have any format you desire and can be easily edited. And they don't need API at all. You just have to [open file for writing]->[write stuff]->[close file] when you create one and [Open file for reading]->[read stuff]->[close file] when you read one. All you need is the standard library of any C compiler. Have you noticed that Civ3 uses an ini text file to manage preferences?

You are right about the benefits and the flexibility to have registry keys managing preferences. But, does an app like yours really need such thing? Having different user profiles may be useful in a corporate network, with shared PC, in which many users need to run an important application with personalized settings. Here, we're talking about small apps which are supposed to help hard-core gamers in doing some tasks. In my opinion, a global INI text file is more than enough.

And, Gramphos, your Civ3MT suffer the same problems i highlighted in my previous post. It poops some files in the Windoze System folder and cannot be uninstalled.

See the issue now? It's not the single app per se that borks the OS. It's the process of [pooping files in System]->[hogging the registry]->[never uninstall] which is often repeated over, and over, and over. It's just a matter of time before something goes wrong. And when something goes wrong in the System folder or in the registry, you usually end up in typing "FORMAT C:\" from a DOS prompt.

Now some frivolous stuff...

tR1cKy, you are a very suspicious man as I can see. Are you a system administrator?

No, and i don't want to be. You end up being insane. I'm a professional programmer with some security skill. My field is mostly Java programming, Unix programming and web-based application on Linux platforms. I rarely develop stuff for Windoze, so i'm not king on it. But i have a good general overview of things, from a programmer's point of view.
Recently i've started some experimentations with DJGPP and MINGW. Interesting stuff, but cannot say much more for now. In my opinion, they're at least worth a try, and they are FREE and OPEN-SOURCE. And please, ditch that horrible installer you're using. An installer that doesn't provide an un-install option is crap.

Wrong forum? Perhaps. Honestly, i wasn't sure about the most appropriate place to post my advice. It is mostly aimed at programmers, so i posted where programmers are supposed to put their stuff. However, if mods feel the need to move it, i won't object.

And don't worry for my PC. It needed to be formatted anyway.

Enough for now. I'm open to replies.
tR1cKy

 

[tR1cKy]

Here's the screenshot of the registry keys creates by Cyber's apps:

 

[ainwood]

Laudable, but if you want all your apps use the same DLLs all you need is to install all the executables in the same directory. DLLs can be loaded from the location where a program is started, so no need to bother the System folder.

What if its a shared DLL (it is) and the user wants to install the two apps into different locations? Is it better to have a plethora of duplicate DLLs?

Now let's discuss Gramphos' statements:

Well, micro$oft in the last years has recommended a lot of things. For example, one of them was "keep autoupdate on, so critical patch are delivered automatically to PC's, and the average user doesn't need to worry about it". Many followed this suggestion, only to feel really sorry when a worm managed to infect one of the mirror servers used by MS to deliver windows updates... the result was hundreds of thousands of lusers (yeah, lusers) being infected by a virus took via windoze update... security, we've heard of it

M$ has also recommended all WinXP users to upgrade to service pack 2 ASAP. Again, many did it, only to find later that the firewall built in SP2, and activated by default, interfered with the auto-update feature of their antivirus program, preventing them to obtain an updated virus signature file... security, did we mention that we heard of it?

Gramphos, be wary of what M$ recommends. Often it's not the best thing to do.

Nice strawman. Completely unrelated to the discussion, and refutes nothing that Gramphos has said...

For what you say on ini files vs. registry keys, well, i disagree. Keep in mind that "newer" doesn't always mean "better". Actually, sometimes it's just the opposite. INI text files are simple, don't interfere with any part of the OS, can be easily parsed, can have any format you desire and can be easily edited.And they don't need API at all. You just have to [open file for writing]->[write stuff]->[close file] when you create one and [Open file for reading]->[read stuff]->[close file] when you read one. All you need is the standard library of any C compiler. Have you noticed that Civ3 uses an ini text file to manage preferences?

I really can't be bothered parsing a text file when there is built-in functions that do things for me. They are there, they work, why not use them?

You are right about the benefits and the flexibility to have registry keys managing preferences. But, does an app like yours really need such thing? Having different user profiles may be useful in a corporate network, with shared PC, in which many users need to run an important application with personalized settings. Here, we're talking about small apps which are supposed to help hard-core gamers in doing some tasks. In my opinion, a global INI text file is more than enough.

And, Gramphos, your Civ3MT suffer the same problems i highlighted in my previous post. It poops some files in the Windoze System folder and cannot be uninstalled.

See the issue now? It's not the single app per se that borks the OS. It's the process of [pooping files in System]->[hogging the registry]->[never uninstall] which is often repeated over, and over, and over. It's just a matter of time before something goes wrong. And when something goes wrong in the System folder or in the registry, you usually end up in typing "FORMAT C:\" from a DOS prompt.

I really don't see what the problem is with adding stuff to the registry or the system folders!

 

[Gramphos]

Well, micro$oft in the last years has recommended a lot of things. For example, one of them was "keep autoupdate on, so critical patch are delivered automatically to PC's, and the average user doesn't need to worry about it". Many followed this suggestion, only to feel really sorry when a worm managed to infect one of the mirror servers used by MS to deliver windows updates... the result was hundreds of thousands of lusers (yeah, lusers) being infected by a virus took via windoze update... security, we've heard of it

M$ has also recommended all WinXP users to upgrade to service pack 2 ASAP. Again, many did it, only to find later that the firewall built in SP2, and activated by default, interfered with the auto-update feature of their antivirus program, preventing them to obtain an updated virus signature file... security, did we mention that we heard of it?

Gramphos, be wary of what M$ recommends. Often it's not the best thing to do.

I didn't say that I follow M$ recommendations, just that they make the OS you say break by the use of the registry.

For what you say on ini files vs. registry keys, well, i disagree. Keep in mind that "newer" doesn't always mean "better". Actually, sometimes it's just the opposite. INI text files are simple, don't interfere with any part of the OS, can be easily parsed, can have any format you desire and can be easily edited. And they don't need API at all. You just have to [open file for writing]->[write stuff]->[close file] when you create one and [Open file for reading]->[read stuff]->[close file] when you read one. All you need is the standard library of any C compiler. Have you noticed that Civ3 uses an ini text file to manage preferences?

Well, you have your opinion, I have mine. The reason why I use the registry is because it's simply (I did have to read from it anyway to get the Civ3 path) so addin some functions to store things in it is not a big deal. It would have been more work to implement a working ini parser, at least at the time when C3CT was made. Now that I actually parse the language file, which actually is a more powerful fileformat than a general INI using them for settings could have been an alternative. Still I don't see a reason to tamper with sometinh that works. And C3MT keeps all its settings in Software\Gramphos\C3MT registry key (of HKLM and HKCU) so it is not very scattered over the registry. I could have used the registry alot more than I've done, but 've not, and as a result of that the utility have some difficulties with non administrative user accounts on XP (I'm working on solve that for later versions)

You are right about the benefits and the flexibility to have registry keys managing preferences. But, does an app like yours really need such thing? Having different user profiles may be useful in a corporate network, with shared PC, in which many users need to run an important application with personalized settings. Here, we're talking about small apps which are supposed to help hard-core gamers in doing some tasks. In my opinion, a global INI text file is more than enough.

Well, I for mayself really hate it when any progeam, howe simple it ever may be keep settings computer global. I can never agree with my brothers on what settings to use, and actually have written a program that swaps ini-files and sometimes full directories of settings, based on the profile.

And, Gramphos, your Civ3MT suffer the same problems i highlighted in my previous post. It poops some files in the Windoze System folder and cannot be uninstalled.

Sure my tool installs Visual Basic 5 runtimes, since it's written in VB. The hard thing about those things are thet they have to be in the system directort or the exe won't load. If I had written it in any other language I could probably have made it keep all files in the program folder. Aside from the VB Runtime library it does install one dll (c3mt.dll) into the system directory. I remember trying to keep that file in the application directory, but it wouldn't work correctlt on Windows 95 for some reason, so I had to install it into the System dir, actually making it harder for me to deal with patches, since they would have to update the dll file in the system directory on load after a patch.

Also C3MT shuld be uninstallable (at least if installed with the installer). I'm not sure why that doesn't work for you.

See the issue now? It's not the single app per se that borks the OS. It's the process of [pooping files in System]->[hogging the registry]->[never uninstall] which is often repeated over, and over, and over. It's just a matter of time before something goes wrong. And when something goes wrong in the System folder or in the registry, you usually end up in typing "FORMAT C:\" from a DOS prompt.

I know well of the so called DLL hell that is when a DLL in the system directory is incpmatible with different parts of the system. (i.e two different dlls under the same name) Therfore I use either only standard DLLs (VB runtimes/zlib (not in C3MT)) that are used by others, and which contain complte version information, and are promised by the creators to keep backward compability (or a namechange would be needed if they dropped old functions) or I use names that to my knowledge (including google search) are not used by others (c3mt.dll).

Also remember that one of the basic ideas with shared libraries is that they should be shared to save diskspace by not installing in more than one location. Now if Windows had symlinks...

No, and i don't want to be. You end up being insane. I'm a professional programmer with some security skill. My field is mostly Java programming, Unix programming and web-based application on Linux platforms. I rarely develop stuff for Windoze, so i'm not king on it. But i have a good general overview of things, from a programmer's point of view.

Well, I'm a selflearned programmer that stared out with QBasic a long time ago. Moved on to Visual Basic, then learned C++. Continued with some Perl for CGI, extended C++ to Java knowledge at some time, and also bult up a PHP knowing. I also know some Haskell, and a few other languages. Still I'm mostly selflearned, even tho I've taken some cources on later days improving my skills in programming generally, and can pick up the basics of most languages (that aren't too obscure). You may well know alot more than me of programming. I only do this as a hobby of mine, and I've never intended to work with it.

Recently i've started some experimentations with DJGPP and MINGW. Interesting stuff, but cannot say much more for now. In my opinion, they're at least worth a try, and they are FREE and OPEN-SOURCE. And please, ditch that horrible installer you're using. An installer that doesn't provide an un-install option is crap.

The thing it that I really would like to change the language of C3MT from VB since it's low and ineffective. If IU had ever thought that the tool would turn that big I'd never started it in VB. However the ammount of work to convert it to another language is way more than I would be willing to do for something I do for free. I'm partly converting costsome functions to c++ implemented functions placed in c3mt.dll.
Regarding the installer I've not updated it for some time now, and maybe should use another. It's just that the one I use have support for VB projects directly with no extra work to be done. It automaticlyy selects the runtime required by the program and makes sure it's installed. That way I'm sure that the installed software runs. And there is an uninstall option to it. I'm sure that I've tested it out. It should actually delete the HKLM registry key for the program on uninstall. (but the HKCU keys are stored for the user to keep their settings)

I may add that I prefere coding on linux over Windows, but since Civ3 is a Windows game I've had to make C3MT a Windows app, or it would not had many users.

Gramphos

 

[Gramphos]

I really don't see what the problem is with adding stuff to the registry or the system folders!

Regarding the registry a large and fragmentated registry database is slower that a database in good condition. I'm not sure about Windows NT/2000/XP (or Me for the matter either) but in Windows 95B-Windows98 SE it's (possible and) a good thing to rebuild the registry files after uninstalling many apps, or had many apps add AND remove stuff from the registry. That process is done from DOS with the regedit command (first you export the entire registry tree and then you pass the command flags that recreate the tree from the exported file) After such an operation you can gain some speed in starting Windows and using any program that reads and updates many values in the registry. You should not use the registry to store images or music files in binarry data, but to store dwords or not to long string values in the registry doesn't really matter for the performance.

Regarding placinf files in the system directory there are two drawbacks of this. One is working against the good of doing so, and one might say that they take out each other, and one is really bad.

The bad one is known as DLL hell and can affect your software in many years from now. The only way you can try to avoid it is to make sure you use unique names of your dlls and that you only use standard DLLs. You still wuld have to rely on that noone else creates a file with the same name as yource, or that a function you use in a dll no longer exists, or is changes, in a later version of the dll.

The other drawback is that some applications don't uninstall their dlls, since they might be used by other application and thus having the folder to grow. With all files in the app folder you can easaly make sure that that app is uninstalled completely. There is also the other way around: When an app uninstalls the dlls that still are required by something else. The first part of this drwaback is a counter to the fact that you save memory by share files over diffeent applications, and it's hard to say where to put the limit.

I know that c3mt.dll actaully should have been in the appliction folder, but I couldn't get that to work correctly, so I had to break a rule of thumb.

 

[Dianthus]

Just popping in to say CRpSuite stores settings in the registry. I too (as well as ainwood/Gramphos) believe that this is the correct place to store these things. So far I haven't had a single user complain about this! (Maybe because they didn't know ).

 

[Cyber Dreyk]

ainwood, thank for the link! Inno Setup is a very interesting utility, possibly I'll use it now.

tR1cKy, I don't undersatand - what the problem is with my registry keys?
You can see one registry key "Cyber Dreyk", and two subkeys - "Civ3FlcEdit" and "Civ3MM". All other subkeys placed in these subkeys - it's a normal practice. To remove on of my projects from registry all what you need - delete on of the high level subkeys or remove "Cyber Dreyk" key at all.

And about DLLs: 1) I don't want to place both ulitities to the same folder; 2) in case the "Check file types association at startup" option is checked, my apps will check and make registration (if it's needed) in case executable will moved to the different folder. It's my decision - I don't want to attach executables to one folder.

P.S. I'm happy that you are not a system administrator! And one more thing - I don't share your negative opinion about MS.

 

[tR1cKy]

This turned out to be an interesting debate!

Cyber, i don't have any particular problems with your apps. But before i explain myself better, let me comment some of your words.

1) I don't want to place both ulitities to the same folder;

But... that's exactly what you're doing. I've downloaded the integrated package (Civ3MM+FLC editor) and it installs the two executables in the same directory.

2) in case the "Check file types association at startup" option is checked, my apps will check and make registration (if it's needed) in case executable will moved to the different folder.

A smart move. Honestly, i didn't think about it. However, assumed that you copy the whole folder and not only the executables, things don't change a bit if you place your dlls in the same directory of the applications. And the space wasted is a non-issue for me: we have 160GB hard disks. A typical WindozeXP installation is 1.5GB. Who cares about 2 or 3 megs of duplicate dlls? And you're sure they will never conflict with anything. They are placed in different locations and are used only by the single application.

As i said before, the problem is not your apps per se. The problem may be explained by your very same words: "it's a normal practice".
Alas, it's a normal MALpractice. Why? It's prone to the so-called "Law of unintended consequences". What if you install 40 or 50 applications made that way? In the best-case scenario, you end up having the System folder hogged by thousands of extra files and the registry filled by thousands of keys. In the worst case, something is conflicting with something else and the whole thing may go titsup. Gramphos has explained clearly the possible drawbacks (see it previous post when he talks about the "DLL hell" problem).

The culprit of this situation is, in part, the tool used to build these apps. Most of you program in visual basic, which i consider the most crappy development tool ever made. Programs made with it tend to be huge resource hogs. It lets you create apps which are System-happy and registry-happy without ever warning you of the possible side-effects. It make you accustomed to fancy visual interfaces, self generating code blah blah blah... until you get stuck with a tool that make you forget the very meaning of what you're doing: coding.

I've met some visual basic "programmers" that don't even know the meaning of "linking" and "compiling". Yeah, click that button and the executable is made. How? No clue. What libraries are linked to my project? No idea. What's their purpose? Duh... Why my project end up being so gigantic and slow? Er...

You may see an example of what i say in this very same thread:

I really don't see what the problem is with adding stuff to the registry or the system folders!

...and:

I really can't be bothered parsing a text file when there is built-in functions that do things for me. They are there, they work, why not use them?

The creator of CivAssist has no clue about the consequences of putting stuff in the System folder or in the registry, and "cannot be bothered" writing code to parse a text file! (and, apparently, cannot be bothered reading the post. The issue was not "write your own code" vs. "use existing libraries". It was "use INI text files" vs. "put stuff in the registry")

I remember the old university days, when creating a simple text parser was part of our final project for Computer Science Laboratory 1, and even the dumbest student of our course was able to code it. Ahh, good times...

Has someone asked himself why VB is so popular among programmers? Because it's good? Yeah, sure...
VB is popular for 2 reasons: 1) it allows even a dumbass to create a program and 2) it's fast. Yeah, it's fast. It's so fast that it's the preferred tool for the "mercenaries of coding". With it you can "work the least, earn the most". And if the end-user find himself fighting with a crappy thing? To hell with the user, gimme the bloody money!!! That's how the mercenaries of coding reason.

But you, Cyber Dreyk, Gramphos, Dianthus, ainwood, you are not mercenaries. You are enthusiasts who made all these useful utilities for the fun of creating them, and for the satisfaction of having positive feedback from people who use them. You did it because you like it, and not for earning money. You don't have to follow deadlines. You don't have to pay a penalty if your project is late. You don't get angry calls at 8:00 a.m. asking if the "damn thing" is ready or not. You don't have a stupid boss who needs to be lectured about the differences between "downloading" and "installing", and can't help copying a document from the desktop to an USB memory stick (yes, i'm serious. i'm lucky he was "relocated" some months ago).

You are not compelled to follow the "mercenary's path". You are not compelled to use a tool that, in the long run, turns competent programmers into VBMs (visual basic monkeys). So, do a favour to yourself and stop using that horrible thing. Try using DJGPP or gcc for Windoze, or even Java. Surely you will struggle at first, and then you'll spend several months only to reach the same level of productivity that you had with visual basic. And then, you'll probably spend more time for doing the same thing you did before with vb. But you'll have an invaluable reward: you'll be real coders who really understand what they're doing when they write programs.

ainwood, ask yourself what would have happened if Linus Torvalds had reasoned the way you do. Today, he would probably being "developing projects" under visual basic and there would be no Linux around.

-------
tR1cKy

 

[Moonsinger]

I've met some visual basic "programmers" that don't even know the meaning of "linking" and "compiling". Yeah, click that button and the executable is made. How? No clue. What libraries are linked to my project? No idea. What's their purpose? Duh... Why my project end up being so gigantic and slow? Er...

That's so true! I myself like to store most of my application settings in the INI files. I even wrote a subroutine to encript certain section in my INI file so that my program can detech any illegal tampering. During the last decade or more so far, I haven't had a single user complain about this! (Maybe because they didn't know ).

I do agree with tR1cKy that real programmer don't do VB. I better run now while I still can before Ainwood and Gramphos see this. J/k, VB programming is cool with me! I just don't hire anyone whose programming experience is only with VB or saying that they like VB better than any other programming languages.

 

[tR1cKy]

Thanx Moonsinger! In the case i find myself wandering around Iowa, would you consider hiring me? I'm sure you're smarter (and prettier) than my former boss

 

[Moonsinger]

Thanx Moonsinger! In the case i find myself wandering around Iowa, would you consider hiring me? I'm sure you're smarter (and prettier) than my former boss

Sure do! Your UNIX experience would definitely put you on top of my list.

 

[Gramphos]

I do agree with tR1cKy that real programmer don't do VB. I better run now while I still can before Ainwood and Gramphos see this. J/k, VB programming is cool with me! I just don't hire anyone whose programming experience is only with VB or saying that they like VB better than any other programming languages.

Like I've said before I used VB for c3mt since it's a good way to quickly get a working interface. General programming is hard to do in Visual Basic, and I do like C++ a lot better (that's a main eason why I keep implementing stuff in my dll instead of in VB). It's just that to make a working userinterface in any other language I'd have to spend mush longer time (at least that was true until I started to mess with translatablity and I think it still is with the third version of the language system)

To the level it is now Java would probably be quivalent in time to achive a spcific task. But like I said before I don't want to reimplement the tool from scratch, and right now I'm stuck with VB. And using it mainly for the UI hasn't had many drawbacks. (Sure I was unable to use some threaded code I wrote in C++ to speed things up, since VB wouldn't hadle haiving callback being called from different threads (or at least I couldn't figure out how to make it work without haiing it crash))

I can't tell what my favorite language is, but I think it actually is C++. So mush more power than VB. But still the language I choose for a project depends on several things. Among those things are the expected complexibility of the userinterface. I tend more and more to create the core program functions in C++ and then make a UI-only app in VB caling the C++ backend for all functions. It combines the strong sides of the both languages quite weel. But also my code library of reusale code payse a big role in this. For Civ3 apps for instance I have several VB classes to deal with the Savefile and the BIC files, and therefore any new app designed by me to work with Civ3 files would most likely use the C3MT codebase and thus be written in VB. To counter that I actually have a (very simple) saveparser/editor written in C++ but it's noway up to the complexity or size (lines of code) that the VB codebase is.


Now, tR1cKy, regarding the fact that we do this for free would give us loads of time from nowhere I have to deny that. I currenlty get less and less time to work on my Civ3 tools and I keep getting more and more real life to do. Still you've not seen the last version of C3MT, buyt the time between versions is going up.

 

[Moonsinger]

Like I've said before I used VB for c3mt since it's a good way to quickly get a working interface. General programming is hard to do in Visual Basic, and I do like C++ a lot better (that's a main eason why I keep implementing stuff in my dll instead of in VB)....

I know, Gramphos! You do not need to explain.

I can't tell what my favorite language is, but I think it actually is C++. So mush more power than VB. But still the language I choose for a project depends on several things. Among those things are the expected complexibility of the userinterface. I tend more and more to create the core program functions in C++ and then make a UI-only app in VB caling the C++ backend for all functions. It combines the strong sides of the both languages quite weel. But also my code library of reusale code payse a big role in this. For Civ3 apps for instance I have several VB classes to deal with the Savefile and the BIC files, and therefore any new app designed by me to work with Civ3 files would most likely use the C3MT codebase and thus be written in VB. To counter that I actually have a (very simple) saveparser/editor written in C++ but it's noway up to the complexity or size (lines of code) that the VB codebase is.

Same here, I use C/C++ for the core functions but use Delphi (instead of VB) for the UI. Since Delphi is pretty much object oriented like C++ and it's a true compiler (not an interpreter like VB), it seems like a very good choice for me. VB has a tendancy to use too many ActiveX/OCX components all over the place and they tend to dump everything into the window system directory; therefore, it seems very difficult to make a clean install/uninstall program. For a quick and not so dirty code on the UI, I like Delphi over VB.

The bottom line, it doesn't really matter much which language we like to program with; it's all coming down to the matter of structures and disciplines. A lot of VB programmers carelessly use "goto" and/or declare unnecessary global variables all over the place; many others do program in VB the same style as they would in ADA.

 

[Gramphos]

Same here, I use C/C++ for the core functions but use Delphi (instead of VB) for the UI. Since Delphi is pretty much object oriented like C++ and it's a true compiler (not an interpreter like VB), it seems like a very good choice for me. VB has a tendancy to use too many ActiveX/OCX components all over the place and they tend to dump everything into the window system directory; therefore, it seems very difficult to make a clean install/uninstall program. For a quick and not so dirty code on the UI, I like Delphi over VB.

I've been meqaning to lear Delphi (and Pascal) but never got around to do it. Regarding OCX components it's trune, and I don't like it either. For simple things as Windows file boxes I've stated to use API calls instead of the CommonDialog control just bacause tuch a simple thing would add an extra ocx.

The bottom line, it doesn't really matter much which language we like to program with; it's all coming down to the matter of structures and disciplines. A lot of VB programmers carelessly use "goto" and/or declare unnecessary global variables all over the place; many others do program in VB the same style as they would in ADA.

Well I've not used gotos since I learned basic, before learned to use gosub, and long before I learned there there actually existed subroutines. I had to learn that the hard way. Seeing my larger proramms turn into spaghetti I had a program that no longer wanted to start due to too little stack space to actually load the main (and only) code block. I had used global variables to transfer data to and from my gosub blocks, that actually coulde be turned directly into subs or functions, with almost no change to the code.

Global variables is something I try to avoid, and onyl use when I can't find another good way to do something in. There are some global variables in C3MT, but most data is handled on object level for save and the bic format (at least in the later versions) It souldn't be a too hard work to take one class and implement it in C++ and have dll routines to access it. Of cource VB can't import classes and class functions from a DLL, but makingit API style, having functions calling the object functions should be doable. The only thing that stops me from start moving classes to the DLL is the fact that I'd have to rewrite the file handling to use api for opening files, and not the VB filenumbers. That is an obstacle that is doable, but would affect many parts of the tool at once, so I've not doen it, and saves it for sometime when I have time to mess with it.

And regarding ADA I only know the basic syntax of it (mainly from reading ADA-style psedo code), and don't really know how to program it, or what conventions you use.

 

[ainwood]

What libraries are linked to my project? No idea. What's their purpose? Duh... Why my project end up being so gigantic and slow? Er...

You may see an example of what i say in this very same thread:

really don't see what the problem is with adding stuff to the registry or the system folders!

...and:

I really can't be bothered parsing a text file when there is built-in functions that do things for me. They are there, they work, why not use them?

The creator of CivAssist has no clue about the consequences of putting stuff in the System folder or in the registry, and "cannot be bothered" writing code to parse a text file!

Well, I put ONE dll in the system folder. And in terms of not wanting to write code to parse a text file, I use GetPrivateProfileString / GetPrivateProfileInt instead. Yes, this means that my program is linked to Kernel32, but is that such a problem? Doing it this way will probably be more efficient than me having to parse the entire file anyway - on the assumption that the compiled, optimised DLL is a bit faster than a text parser that I could write in VB. In fact, I prefer to use windows APIs over VB standard libraries, because they're faster (eg. for file searching I use FindFirstFile, FindNextFile etc).

(and, apparently, cannot be bothered reading the post. The issue was not "write your own code" vs. "use existing libraries". It was "use INI text files" vs. "put stuff in the registry")

Might want to read that again:

INI text files are simple, don't interfere with any part of the OS, can be easily parsed, can have any format you desire and can be easily edited.And they don't need API at all. You just have to [open file for writing]->[write stuff]->[close file] when you create one and [Open file for reading]->[read stuff]->[close file] when you read one.

I remember the old university days, when creating a simple text parser was part of our final project for Computer Science Laboratory 1, and even the dumbest student of our course was able to code it. Ahh, good times...

Implying that I'm below your dumbest student?
Well, I have written text parsers. You're quite happy to use standard C libraries, I'm quite happy to use standard Windows ones.

ainwood, ask yourself what would have happened if Linus Torvalds had reasoned the way you do. Today, he would probably being "developing projects" under visual basic and there would be no Linux around.

-------
tR1cKy

Well, he's got a slight advantage over me in terms of time, knowledge of assembler etc.

Interesting that the concept behind Open Source is that people use other peoples' code for their own purposes, and the developers can look at it and improve it. Is this so different in concept from me using standard windows libraries?

If I thought like Linus Torvalds, I would never have produced anything as I'd still be trying to write new controls from scratch.

BTW - the next version of CivAssist is being written in C#. It is a lot more flexible and useful than VB, but I fear that some people will still consider that since its a M$ development environment and M$ developed language....

 

[ainwood]

The bottom line, it doesn't really matter much which language we like to program with; it's all coming down to the matter of structures and disciplines. A lot of VB programmers carelessly use "goto" and/or declare unnecessary global variables all over the place; many others do program in VB the same style as they would in ADA.

That's the thing I'm trying to learn. Whilst I've never taken a course, I do read up on these things extensively.

The original CivAssist is a mess. Some of it is because of the limitations in VB - For example, it doesn't support inheritance; only interface inheritance, so I have unneccessary repetition of similar code in multiple classes. But I minimise use of global variables, and do make sure to destroy objects when I'm finished with them. The rest is because of the way I've added-on to it - seeing as I don't have a true object-orientated model to use, there's not always a lot of base stuff to go back to.

In the new version, I am writing it in partnership with someone who actually knows what they're doing - it does show-up the limitations of VB, and virtually every line of code I write is being scrutinised to ensure that it is efficient and structured.

Its a great learning experience.


BTW - I haven't used gosub since I programmed on a Commodore 64, and goto is restricted solely to the error handler.