Important advice for programmers! Please read!!!

[Moonsinger]

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.

When I mentioned ADA, that was really just a figure of speak...I was implying a well structure and well organized programming style. I haven't touched ADA since my university days like an eon ago. I don't really know anyone who actually still program in ADA these days.

 

[Cyber Dreyk]

This turned out to be an interesting debate!

Yes, it's a very interesting...

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.

Yes, but about one year it were two separate projects.

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.

I argee with you. Now I'll use the "Inno Setup" installer with uninstall possibility and place all DLLs to the same folder as executables.
But I disagree about using INI files - I would prefer to use registry keys.

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...

Are you sure? I have never using VB, honestly speaking I don't like this language at all. I'm surprised that you cannot distinguish between VB and C++ utilities.

Thank you for constructive criticism!

 

[tR1cKy]

@Cyber: i just run the executable, didn't poke at it with the hex editor... frankly, i cannot distinguish between them (usually - sometimes i recognize a program written in VB for its being bulky, cpu-killing, slow and crappy)

@ainwood: man, stop playing dumb with me please. You have taken a single line of text from an half-page speech and commented it as it was the only thing i've said... c'mon!

@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.

 

[Gramphos]

re working together, we actually do, in some sence, however we are not using the same libraries for several reasons. One important is that our utilities have different purposes. My need to be able to save back stuff, while others only need to read stuff. Sur, if we had worked together from start it would have been good to create one multifunction library, and then build tools on it, but since we already had a base code, different for each programmer creating a library would not only involve the work of rewriting many functions, but also require each tool to be updated to work with the library. That would be many lines of code to change just because we should be able to share some code. If the game still had been undergoing changes it could possible have some more benefits, since it would be easeier to keep all untilities compatible, but since that' not the case there is no reason to reimplement everything.

 

[ainwood]

@ainwood: man, stop playing dumb with me please. You have taken a single line of text from an half-page speech and commented it as it was the only thing i've said... c'mon!

I'm not playing dumb. Part of the argument that you presented for .ini files was that they are easily parsed by the dumbest student in your course. I simply want to know what the advantage of parsing the file yourself is over using the in-built functions in the APIs, or more importantly, what is so bad about the windows API that I should write myself a parser wrapper.

 

[sabrewolf]

fascinating discussion among the code gods of the civ3-universe

but does it not all come back to the fundamentalistic question of MS-proprietary versus open standards? there is a war out there and thousands of people who would fight to the death for their choice

but anyhow, on topic:

PRO registry:
- 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.

- the registry is created for exactly this reason. there are 5 main branches of which ons is extremely messy (HKCR) and the others are more or less nicely sorted. 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). anyhow, Cyber's and other people's utils write stuff neatly into a subkey in the correct place without. it is easily locateable and removeable. so where is the problem?
i believe the only nasty thing of registries is the registration of DLLs with their UUIDs (32 digits). but that is another topic.

DLLs
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

languages
i never liked basic. it's an inconsistent language, limited in its possibilities and uses a new line as delimiter!!! (ever tried importing a part of code from another document? you spend half the time on correcting line breaks ). but VB6's had the great GUI builder that was the main attraction and the reason for VB's success. but now with Visual Studio.NET you get this GUI builder for all languages! and of these new languages especially C# comes to mind! i used to love java and despise C++ (because i met them in that order), but now C# has cleary overtaken java in my popularity. i still believe javadoc is neater than the .NET way of commenting with pseudo-XML and the crappy output style, but in other ways i like it a lot!
is it proprietary? yes! but keep in mind that with Mono (go-mono.com) you can program, compile and run most .NET assemblies (not using the Windows.Forms library) on linux & co.
gramphos, you should try C# with .NET. you'll want to forget C++, VB, DLLs and all that stuff quite soon


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

 

[Chieftess]

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.

*eh em* I'm forced to used Visual Basic at work (they want all Microsoft products, which means Visual Basic and VB.NET).. But, atleast we're using C# for the CMS system we're using. Funny, I feel right at home using double slashes and semicolons. VB feels like some... kindergarten book.

*runs away from Ainwood and Gramphos too*

 

[Moonsinger]

I'm not playing dumb. Part of the argument that you presented for .ini files was that they are easily parsed by the dumbest student in your course.

I think that was just a figure of speak. I think he just wanted to emphasize that INI file format is easy to use.

I simply want to know what the advantage of parsing the file yourself is over using the in-built functions in the APIs, or more importantly, what is so bad about the windows API that I should write myself a parser wrapper.

Well, I think that was just another misunderstanding...because there are actually a very rich set of windows API for working with the INI files. Microsoft had been using the INI files on their Win3.11, WinNT server or older windows platform long before they came up with the Registry thing. I can't speak for tR1cKy, but since I often port my code over to the UNIX server, by using the INI format, I don't have to change my codes much (since I implement an INI parser module for UNIX ).

 

[Moonsinger]

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

You are right about that!

 

[Gramphos]

gramphos, you should try C# with .NET. you'll want to forget C++, VB, DLLs and all that stuff quite soon

Someday I probably will try it. Just that with my current, very limited, time available for programming it will have to wait.

 

[tR1cKy]

I think that was just a figure of speak. I think he just wanted to emphasize that INI file format is easy to use.

I think you're right...

Since the API vs. non-API issue seems so important in the whole matter (at least for someone), let's talk a little about it. I find obvious that the best way to deal with an INI file depends of how data are stored in.
Usually ini files have a very simple format, like single rows which contain data in the form of "VARIABLE=value". In this case things are so easy that you don't need any particular function. In fact, all you need is:
- the open and close functions for opening and closing the file
- a function to collect a single row of data from the opened file
- a split() function
See that example in Perl:
[pre]sub EatIniFile {
open (FP, "<FileName.ini");
while ($Line=<FP>) {
chomp($Line);
if ($Line ne "") {
($Var, $Val)=split(/=/, $Line);
$HashVar{$Var}=$Val;
}
}
close (FP);
return(%HashVar);
}[/pre]
Knowing what are the variables stored in the ini files and what type of data they should contain, it's a non-issue to extract them properly from the hash table. If you need string conversions functions, they are part of the standard C library.
Alas, putting Perl code in your C program is not a viable option in Windoze, while in Linux it's pretty easy (IMHO, the best way to understand how much Windoze SUX is to get accustomed to Linux), so you would probably need to code it in C, but the only function you may need to implement is the split(), which is usually done in a few minutes

When there are complex data structures, the whole matter is different. But at this point, one should ask himself (or herself) if the ini file is the best option. I'm sure that sometimes putting stuff into the registry is the best way, but complex data usually are best put into a binary file, in a predefined format.

See again the Civ3 example. It stores simple "environment variables" into a text ini file. For complex data, a binary file (civ3mod.bic) is used. It would be a real mess to put all the stuff of civ3mod.bic into the registry!!! (and even worse in a text file)

About languages, i've been quite surprised to read this:

is it proprietary? yes! but keep in mind that with Mono (go-mono.com) you can program, compile and run most .NET assemblies (not using the Windows.Forms library) on linux & co.
gramphos, you should try C# with .NET. you'll want to forget C++, VB, DLLs and all that stuff quite soon

Believe me or not, it's the first time i hear someone saying that C# is good. Usually what i hear about C# may be synthethized in one word: crap.
Let me say something about Java (Sun's java, not the joke that M$ J++ is):
- On Linux, and on every platform in which the java virtual machine is present, you may run the very same BINARY you've built on Windoze.
- the java virtual machine must be downloaded and installed separately, but it's just a few megs of download, installation is painless, and the size of an executable is typically 1/10 to 1/20 of the size of the same program written in Visual Crap.
- the java development tool is FREE and its size is about 70 megs. M$ development tools cost loads of bucks and their size is enormous.
- source code of every java library is available, with the exception of the "bridge libraries" used by the java virtual machine to translate bytecode into native machine code (the reason is obvious).
- the whole documentation of all the function implemented is easily browsable for sun's website and may also be downloaded and used offline (download is about 60 megs of zipped archive).

Sabrewolf, can't you see beyond M$ proprietary stuff? To your side, i can say that EVERYTHING looks great once you realize the crappiness of vb. But have you tried Java or DJGPP? There's no reason to be loyal to M$ (unless you work for them, of course).

 

[sabrewolf]

Believe me or not, it's the first time i hear someone saying that C# is good. Usually what i hear about C# may be synthethized in one word: crap.

a matter of opinioin... i'll go through your points one by one...

Let me say something about Java (Sun's java, not the joke that M$ J++ is):
- On Linux, and on every platform in which the java virtual machine is present, you may run the very same BINARY you've built on Windoze.

that is the aim of the .NET framework. in fact, the architecture is pretty much the same (microsoft "borrowed" several ideas from sun's java). the CLR (Common Language Runtime) is the equivalent to the JVM/JRE, ByteCode is like MSIL (intermediate language), etc.
CLRs currently only exist for windows machines and via the Mono project for many other OSs.

- the java virtual machine must be downloaded and installed separately, but it's just a few megs of download, installation is painless, and the size of an executable is typically 1/10 to 1/20 of the size of the same program written in Visual Crap.

again, this changes with .NET. as they also rely on libraries, packages (called assemblies) etc. the files are not much larger than java binaries. in fact i presume they are smaller as the libraries are richer for many things, especially GUI-based stuff

- the java development tool is FREE and its size is about 70 megs. M$ development tools cost loads of bucks and their size is enormous.

this is definately a downside of microsoft's environment! i give you this argument
(for the record: mono project includes a free C# compiler...)

- source code of every java library is available, with the exception of the "bridge libraries" used by the java virtual machine to translate bytecode into native machine code (the reason is obvious).

also true, but otoh the CLR and all core libraries are fully standardised at the ECMA and M$ assists companies such as ximian (mono producer, now bought by novell) to develop alternate CLRs

- the whole documentation of all the function implemented is easily browsable for sun's website and may also be downloaded and used offline (download is about 60 megs of zipped archive).

javadoc is imho nicer and faster. but on MSDN you can get all documentation too with much more examples in all 4 languages. downloaded version however is only for MSDN-subscribers (costs)

Sabrewolf, can't you see beyond M$ proprietary stuff? To your side, i can say that EVERYTHING looks great once you realize the crappiness of vb. But have you tried Java or DJGPP? There's no reason to be loyal to M$ (unless you work for them, of course).

i've used java. in fact i started OO development with java. and i still like it very much! but that does not stop me for also respecting C#/.net.
i'm afraid i have never used DJGPP and my C++ experience is limited to debugging a crappy program using.... VS C++


tR1cKy:
for many reasons java still is superior to .NET. especially when dealing with platform independence and standards interoperability (eg. CORBA).

but when dealing with web services/web application, or when working in a purely microsoft-based environment (like it or not... most companies still do), then .NET does have advantages. the IDE is one of the best IDEs in existance (Visual J++ was several times voted best Java IDE!!!) and with the language independance of .NET (you can use ANY supported language and compile it to the same intermediate code).

 

[Gramphos]

See again the Civ3 example. It stores simple "environment variables" into a text ini file. For complex data, a binary file (civ3mod.bic) is used. It would be a real mess to put all the stuff of civ3mod.bic into the registry!!! (and even worse in a text file)

Have you ever looked at Civ2?

 

[Chieftess]

Have you ever looked at Civ2?

And I actually liked it in a text file...

 

[Gramphos]

The thing is that comparing application settings with rules for a game is absurd. Also one of the main reason why games use ini file is that those settings might have to be alerted through the ini, since not everything can be changed with the UI. That makes it easier for the users to edit the settings.

One other is portability, many games are ported to mac, and if you want to use the same setting system you can't use the registry. however, I never intended to port any of my tools.

 

[Aya]

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.

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.

- 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 :-

; 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:

# 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.

- 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:

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!

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.

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.

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.

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:

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?

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...

    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...

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...

```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.

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".

@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.

 

[IbnSina]

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!

I think that about covers it... As an old Unix programmer (who has written a few tens of thousands of lines of C++ for M$ out of necessity) I've always been annoyed at the very concept of the registry. I don't want somebody else's software messing with mine, and I don't want my program accidentally to be responsible for disabling someone else's. I prefer to keep away from the registry as much as I can - using it only encourages them.

I'd like to add my vote for text .ini files. It may be that microsoft has debugged their parsing tools by now, but a few years ago the MFC tools for binary read/writes were terrible. I finally found that if I wanted to save time, I needed to stick with ascii text for my configuration files. On the other hand, that is probably just the old Unix programmer in me talking now...

 

[Moonsinger]

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)"....

Very funny and true too!

 

[sabrewolf]

First up, this is my first post, so I'd appreciate not getting flamed from fellow posters until at least my second post.

*snip*

hi aya

thanks for your long answer, especially replying to my post. i feel honoured!

i must admit that this is the by far MOST impressive 1st post i have EVER seen! my civ3-home is actually apolyton, but i spend quite some time reading here. but you.... absolutely incredible


concerning your full post:
most things were nothing contradictory to my own post, except the part about hierarchical INI files. of course, i never thought of that part and considering it hierarchical. but i would still see it more like a scope when using the cornered braces. it's not endlessly nestable (probably possible, but very seldom).

on your suit developer vs. hippie programmer (btw: ): afaik registries are not only compressed large INI-files (although exports produce that). iirc they are really tree-based and are fast for precisely that reason. of course i could be wrong there. it's just something i picked up from a fellow student a few years ago...

cheers!

 

[sabrewolf]

aya:

btw: i found this psycho programming language too called brainfück: http://www.muppetlabs.com/~breadbox/bf/

see example: http://www.muppetlabs.com/~breadbox/bf/quine.b.txt

pretty impressive, although debugging may be a little tedious


ps: there is a COMPILER for brainfück that is only 117 bytes long: http://www.muppetlabs.com/~breadbox/software/tiny/bf.asm.txt
man, there are some sick bastards out there