teamspeak versions have different sizes?

[bwana]

the standard client is version 2.0.32.60. If i go to the teamspeak folder and check the properties of the executable it has a size of 1.36 meg. n the download section is a file which is version 2.0.33.7 but it is only 523 kb. What are the differences, which should i use for vista and where are the release notes?


btw, if i alt-tab out of a game while using team speak and go back into it, the game seems to crash at a random unspecified interval afterwards whereas if i do not alt-tab out of a game, i have no stability problems. i know this is not teamspeak's fault but it may help people who are having vista problems-DONT ALT-TAB.

[Peter]

2.0.33.7 is a newer version of the client, go use it. The changes are probably in a post on the Developer Releases board of this forum. The size difference is, I believe, due to binary compression that was only applied to the new version and not to the older one.

[ANR Daemon]

Why compression? Compressing executable is a breaking of core idea of multitasking OS organisation - reuse code/separate data.

[Peter]

Why compression?
Saves us bandwidth, and results in faster downloads for the users.

Compressing executable is a breaking of core idea of multitasking OS organisation - reuse code/separate data.

This is bullshit, operating systems do not try and "reuse" code of different executables. What operating systems *do* is to reuse code of dynamically loaded libraries (.dll, .so, .dylib), but since we are speaking about the TS Client and not some library that some other application is going to be using, compressing the executable is not going against any multitasking OS ideas.

[bwana]

binary compression? duh, what does that mean? when i downloaded the update, i received an executable, not some zip or rar file. comparing the executables is what i'm doing. how do you do binary compression on an executable? isnt it already compiled (and hence compressed). ? Or did they just strip out the debugging code?

[Peter]

Compiling is transforming human readable (if you have the gift that is) source code into machine executable machine code. Compiling has nothing to do with compression, infact it is often the case that the source code is smaller than the resulting machine code binary, hence compiling is often similar to the opposite of compression.

Now it is possible to compress executables, just try and rar, zip or bz2 some executable (e.g. that 1.36 meg file of the 2.0.32.60 client). You will be able to reduce the size significantly (maybe to something around 500 kb). Of course a .rar is no longer executable, and here is where special tools come into place that don't destroy the fact that the file is executable. Basically when you run the binary a small "wrapper" code will go ahead an decompress the compressed executable, and then jump into the entry point of the original binary, hence transfering control and making everything behave like the uncompressed binary would have.

[bwana]

so which compressor do you use? I remember a slew of these kinds of things floating around. Remember when a 60 MEG hard drive cost close to$1000. YES, I said 60 meg. That was back in the day of the fat MacPlus (512kb of ram) when most good executables were hand assembled in assembly. DiskDoubler for example transparently compressed and uncompressed EVERY single file on your hard drive. If you removed disk doubler, then your files were useless because they were compressed (although macs dont use the concept of a extension to indicate the owning application- they have something called a resource fork and a data fork-actually i dont know if they still use that architecture) Anyway, if you wanted to be able to give someone else a file who didnt have diskdoubler, you could incorporate the diskdoubler decompressor into the file. the file would transparently decompress in ram and then execute. Most compressors have such 'self decompressors' than can be incorporated int the file - AutoStuffit for example, etc.

However, given that Zip files are so common and that even windows allows unzipping, why dont you just provide the Compressed version of the file? Then you would save even more bandwidth because the compressed file would be even smaller-it would not have to carry the decompression code too.

[Peter]

This thread is boring me, why do we even care? Lets summarize:
(1) The binary works fine
(2) The binary is smaller (which is better for bandwith and download time reasons)
(3) The binary is *newer* and contains less bugs...

Use it already :/

[Reedy Boy]

This thread is boring me, why do we even care? Lets summarize:
(1) The binary works fine
(2) The binary is smaller (which is better for bandwith and download time reasons)
(3) The binary is *newer* and contains less bugs...

Use it already :/

/me votes to close the thread :D


Short Answer: They're the developers, and they can do what they want

[maxi1990]

I asked this also myself some time ago. But i came to the conclusion that it works fine.

/me votes for a closed, too ;)