First up, this is my first post, so I'd appreciate not getting flamed from fellow posters until at least my second post.
I recently purchased Civ3 complete, having been a fan of Civ, Civ2 and SMAC. As you can imagine, my free time has suddenly diminished. I checked out some of the sites linked from the civ3.com website, and found this to be the most popular. Tried out a few of the modpacks, and instantly wanted to have a go at making my own. So I just installed Civ3Flc and Civ3MM, hoping they will cause me less pain than the C3C scenario editor.
sabrewolf said:
fascinating discussion among the code gods of the civ3-universe
Indeed. This one actually made me bother to register. I've been a software developer for some time now, and I always enjoy a good argu^H^H^H^Hdiscussion about these sorts of things.
sabrewolf said:
- having a tree-like structure is much more efficient and logical than "flat" .ini files. the latter works fine for asorted stuff like in the civilization3.ini file where each option is independent of the other. but as soon you use constructs which are based on hierarchy or repetition (eg. settingA, settingB, etc), treelike structures are superior.
This is not quite true. Even back in the days of Windows v3.x, the INI file format had a rudimentary hierarchy, although it could only support 2 levels. This has remained even in system INI files in WinXP, albeit for back-compatibility only. Check this from my C:\WINDOWS\system.ini :-
Code:
; for 16-bit app support
[drivers]
wave=mmdrv.dll
timer=timer.drv
[mci]
[driver32]
[386enh]
woafont=app850.FON
EGA80WOA.FON=EGA80850.FON
EGA40WOA.FON=EGA40850.FON
CGA80WOA.FON=CGA80850.FON
CGA40WOA.FON=CGA40850.FON
In addition to the "key=value" lines, there are some lines which begin with a semicolon, and some which are enclosed in square brackets. The former are merely comments to be ignored by the parser, whereas the latter are hierarchical groups.
Roughly translated, this file contains the root keys: drivers, mci, driver32, and 386enh. The "drivers" key contains the subkeys: wave and timer, the mci and driver32 contain no subkeys, and the "386enh" key contains the remaining subkeys.
The Java programming language came with a parser for a similar format built-in to the API. The Java "properties" file is similar to the INI file format, but doesn't support nested keys, and comments have a different delimiter. They had approached the nested keys problem in a much better way IMHO, that is by using the key names to denote hierarchy. Example:
Code:
# This is a comment :P
key1.subkey1=value
key1.subkey2=value
key2.subkey1=value
...
This system should work perfectly fine in an INI file too. And of course there's XML which is pretty good for hierarchical config.
sabrewolf said:
- the registry is created for exactly this reason.
Agreed. The registry is the correct place to put configuration settings for Windows software. IIRC one of the reasons it was introduced in Windows 95 was to replace all those thousands of INI files scattered all over your hard drive, so (assuming the keys were sensibly named) the user could easily find the place to reconfigure software settings. The only important distinction between the registry and config files, is in the amount of data you need to store. Since all programs have to share the same registry, it's considered good practise not to store too much data in the registry.
Actually, I just had a play with regedit, exported a registry file. The format looks a tad familiar:
Code:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Foo Software]
[HKEY_LOCAL_MACHINE\SOFTWARE\Foo Software\SuperFoo Image Processor]
"DefaultImageFormat"="GIF"
"RegistrationKey"="76A2F9B2"
Ignoring the top line, it looks a lot like our old friend, the INI file. But now we have the hierarchy of keys stored in what was previously used for a 2-level hierarchy, and the strings have (sensibly) been quoted to allow for leading or trailing whitespace.
I can just imagine the conversation at Microsoft:
Suit programmer: Hmm. Just finished this new program that corrupts all your system files so that you have to reinstall Windows. I'm gonna call it "The .NET Framework (tm)". But for it to work, I'll need to put a new INI file in C:\WINDOWS.
Hippy programmer: No, man! Everyone keeps doing this, it's starting to bug me, dude. We should have... like... one *big* INI file with everything in it.
Suit programmer: Hmm. Well... it'll need to have it's own editor program. A file that big is bound to crash notepad.
Hippy programmer: Yeah, man! And then we could... like... compress the data on disk to save space.
Suit programmer: Hmm. Okay, but it'll need a catchy name.
Hippy programmer: Dude! How about "regedit".
Suit programmer: Perfect!
sabrewolf said:
there are 5 main branches of which ons is extremely messy (HKCR) and the others are more or less nicely sorted.
AFAICT the HKCR key is merely a symlink/shortcut to HKLM\Software\Classes.
sabrewolf said:
the great thing is that HKEY_CURRENT_USER changes depending on who is logged in. imho it is much better than the idea of c:\documents and settings\user name\local settings\... (whoever had this idiotic proposal should be shot! unix's "/home/" is more imho cleverer).
This is exactly the reason why the HKLM and HKCU keys both have a "Software" subkey. The idea is that application developers can split the configuration settings into those which apply to all users, and those which only apply to the currently logged on user.
sabrewolf said:
i believe the only nasty thing of registries is the registration of DLLs with their UUIDs (32 digits). but that is another topic.
I think that only applies to ActiveX controls and other "special" DLLs. I've never needed to register any DLL I ever wrote, but I wonder now if this is the case with Civ3Flc & Civ3MM.
For configuration, I don't really mind too much if the programmer decides to go with the registry, or a text file. Either is much nicer IMHO than one of those proprietary .dat files which is probably just a C struct dumped straight to disk, although by that stage, the programmer really ought to have a half-decent configuration editor built-in to the software, and I've seen a few that don't even live up to the standards of vi/emacs/notepad.
However, what I do mind is programs that dump a load of crap in your C:\WINDOWS folder (or any subfolders - yes, that includes System32), especially if they are incapable of cleaning it up when they are uninstalled.
sabrewolf said:
i personally prefer
locally storing the DLLs versus putting it in the system32 folder. in fact i consider that a major sin to do the latter, even if you need it in more than one program. disk space is usually the smallest of problems in today's computers and beast.dll is for example only 25kB or so
I'd go as far as to say that I'd quite willingly punch anyone who writes code that installs any files in the WINDOWS folder or subfolders, with the possible exception of device driver coders, who may have no choice. These folders store the core of the entire operating system. Now, even if you know what you are doing, the poor user who has to clean up the folder after an unsuccessful uninstall of some software, could quite easily delete a shared DLL which causes Windows to stop working properly (a rather easy feat nowadays).
Since the System32 is always in the DLL search path, it is often used by programmers to store DLLs (amongst other things) which are used by several programs. This is bad for several reasons:
1 - Clobbering: Since it is a shared area, there's no guarantee that if you write a DLL with an unimaginative name such as "mylib.dll", and put it into System32, that it won't clobber another one written by an equally unimaginative programmer. And a more obscure filename (8DG1G89C0F.dll) is only marginally better.
2 - Locking: Quite a few installers tend to assume you don't have some of the files which are probably already installed on a virgin Windows machine. Things like VBRUN60.DLL, the MS Visual Basic 6.0 runtime library. Problem with this, is that as a shared library, it will be "locked" by the OS as long as *any* VB program is running. Same thing applies to some ActiveX controls. Now unless you're using an expensive professional installer which can cope with updating locked files, your installer will probably fail to work. And even if it does work, the user will have to reboot the system for the install to complete (which I hate).
3 - File System Limitations: IMHO there's too many files in that folder already. Every time you add the file to the folder, subsequent accesses to the folder (which is obviously happens quite frequently) will be marginally slower. Now if every program stuffs a bunch of DLLs in there, after a while, it's gonna seriously cripple your PC to search the whole directory every time it needs to find any DLL. This problem is amplified by the fact that a lot of very expensive commercial installers still fail to clean up fully after an uninstall. If I was a cynic, I'd say it's the same companies who deliberately write broken installers, so they can also sell these independent "uninstall" programs (e.g. Norton CleanSweep)
4 - Peace of Mind: Maybe this only applies to me, but I feel much more comfortable when every program installs all its files into a subfolder of C:\Program Files, or similar. I then know where all the files for each program are stored so I can delete then ALL when the program starts to irritate too much.
As for where *to* put the shared DLLs, there are a couple of "nicer" options:
tR1cKy said:
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.
This is probably the best option if you don't mind having both EXEs in the same folder, but for separate distributions using a shared DLL is probably unwise.
A lot of software companies came to a compromise by using another folder for all their common DLLs. e.g.
C:\Program Files\FooSoft\SuperFoo Image Processor
C:\Program Files\FooSoft\SuperFoo Sound Processor
C:\Program Files\FooSoft\Common Files
... and then ensuring the final path is included in the DLL search path.
Another standard that I believe originated from Microsoft, is the use of the "C:\Program Files\Common Files" folder. Perhaps your shared DLLs could go somewhere in there?
sabrewolf said:
languages
i never liked basic...
Ah. We're into the domain of "holy wars". Kinda like vi vs. emacs, or similar.
After having toyed with as many languages as I could find, including some rather unusual ones, such as the humourous Intercal...
Code:
DO (5) NEXT
(5) DO FORGET #1
PLEASE WRITE IN :1
DO .1 <- 'V-":1~'#32768c/#0'"c/#1'~#3
DO (1) NEXT
DO :1 <- "'V-":1~'#65535c/#0'"c/#65535'
~'#0c/#65535'"c/"'V-":1~'#0c/#65535'"
c/#65535'~'#0c/#65535'"
DO :2 <- #1
PLEASE DO (4) NEXT
(4) DO FORGET #1
DO .1 <- "V-':1~:2'c/#1"~#3
DO :1 <- "'V-":1~'#65535c/#0'"c/":2~'#65535
c/#0'"'~'#0c/#65535'"c/"'V-":1~'#0
c/#65535'"c/":2~'#65535c/#0'"'~'#0c/#65535'"
DO (1) NEXT
DO :2 <- ":2~'#0c/#65535'"
c/"'":2~'#65535c/#0'"c/#0'~'#32767c/#1'"
DO (4) NEXT
(2) DO RESUME .1
(1) PLEASE DO (2) NEXT
PLEASE FORGET #1
DO READ OUT :1
PLEASE DO .1 <- 'V-"':1~:1'~#1"c/#1'~#3
DO (3) NEXT
PLEASE DO (5) NEXT
(3) DO (2) NEXT
PLEASE GIVE UP
...the wacky Befunge...
Code:
028p038p108p018pv
vp91+56p900< v_v#!-+1"!":< >:"<"-!#v_:"^"-!#v_ v
>"*"09g:19g\19gg29p p 29g28g #^_ :" "-!#v_:"v"-#^_ v
^p91+g91g81p90+g90g 8 0pg91g90g92$ < <
>: >38g7p38g1+38p^p811p800<
>28g!28p ^p810p80-10< <
^p81-10p800 <
^p810p801< _v#!-">":<
^ -"0":_v#`\+1"9":_v#` -1"0":< #
> # >:"!"1+-!#v_v
#######################>19g+\48gp ^ p #82!g82<
0"!dlroW olleH">v # ^ g7-1g83_v#!-":":<
,: # >$, ^ < #>:"p"-!#v_v
^_25*,@# v_^#-4:_v#-3:_v#-1:_v#-2:\g7p83:-1_v#:g83<2<
####################### >:5-#v_v$ ^ # 0 #<
^ _v#-6< > $6 v >$09g+48p1 >> ^
>$0> # ^ <
v_ ^
>* ^ ^3_v#!-"_": <
>:","-#v_4 ^
^5_v#!-"*":<
> #@ ^
...and the minimalist Unlambda...
Code:
```s``s``sii`ki
`k.*``s``s`ks
``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk
`k``s`ksk
I think I'd prefer VB to any of these.
I've pretty much come to the conclusion that all languages have strengths and weaknesses, so just pick one that you're comfortable with (providing it can do what you need).
But on a more basic level, I guess I look at it like this: If someone has a passion to write something useful for the Civ3 community, and only knows VB, then I'd rather have it in VB than not at all.
sabrewolf said:
to come to a conclusion: i doubt either "side" will be able to convince the other. tR1cKy clearly despises MS-unique stuff while the others of you do not. even though this thread is completely harmless, it's a fight of religions
That pretty much sums it up. Just remember that whatever your favorite development environment, there are a plethora of competing standards, so just try to follow the one which seems the most "sane".
tR1cKy said:
@everyone: did someone think about an open-source project? It's obvious that some basic function, such as reading SAV and BIC/BIQ/BIX files, are always the same. It would be better to build a single set of standard libraries, which everyone can use, rather than having everyone develop its own version. You can save a lot of time working in team that way
This sound like a great idea to me. I could certainly contribute... an INI file parser.
Question is, are the people who wrote BIQ parsers likely to share their source? It'd only take a couple of minutes to set up a project on Sourceforge.
Apologies for the length of this post, but I needed a break from playing Civ3.