x64 native version of trillian (tm)

[Downloads]

hi, a x64 bits version will be released (xp x64 and vista x64)?

Please, do the x64 bits version for win xp and vista please :)

thanks for reading this message :)

regards

[DiamondNRG]

What would coding Trillian for 64 bit do? Make IM's go faster? There is really no need for this (yet).

The current version works just fine on 64 bit operating systems.

[wagnerr52]

Trillian uses Quicktime for A/V and Flash for widgits. They cannot make the switch to 64-bit until both of those applications have been released in 64-bit. As far as I know, neither of them have.

[Hielke Hoeve]

can't imagine that you can't use trillian in 64 bit and make calls to 32 bit applications, the underlying framework detects if the 32 bit codeshould be executed in WOW32 (32 bit emulator) space or in normal space.

[DiamondNRG]

But why not just run 32 bit Trillian on your 64 bit OS? It isn't like it will actually make your IM's go any faster ;)

[wagnerr52]

Check out http://www.virtualdub.org/blog/pivot/entry.php?id=42

64-bit applications cannot directly plug into 32-bit dlls. You can set up some games by running a separate 32-bit process and using IPC between the two processes, but its difficult to get working, limited, and rather 'hackish'. There's not much use upgrading to 64-bit until the programs you need to use have already upgraded.

[aemulus]

What would coding Trillian for 64 bit do? Make IM's go faster? There is really no need for this (yet).

The current version works just fine on 64 bit operating systems.

It would allow for faster loading, also utilizing the 64bit API's would allow for the program to natively support multi-core processors which could offset computational time when decrypting/encrypting messages. The features that mention "you should have a really fast processor", will actually work at a reasonable speed for those of us who already have a "really fast processor" ( aka Athlon 64 X2 4400 -- I know there are faster processors, but if this isn't fast enough for a spell check feature, I am not quite sure what is.... Cray X1 ? ).

Also, when people send like a million happy emotes to your screen, utilizing the full 64bit core, will allow for this information to be processed twice as fast, thus reducing entire machine lag. The more bits that can be processed simultaneously, the less memory is necessary, which really is offsetting information being loaded from the true bottleneck, the HD. 64 bit processing will not help with HD speed, but overall, I believe it is a good idea. Leave the 32 bit apps to things like notepad and windows calculator. Do us all a great joy, and when making your API declares, include "system64.dll" and use int64 for calculations.

Cheers,

Dan

[aemulus]

For rendering video, perhaps it would be time to change the technology from QuickTime to something a bit more robust, say... mm... i dunno... check out the sources for VLC, and see if you can implement some of that technology into the streaming options for captures. This would allow for better quality and faster compressed video such as DivX, or OGM, etc. An entire plethora of options become available for compressed video streams. The best I could ever get this video capture stuff working is from trillian to trillian anyway.

Also, just a quick FYI:: It is possible to create a quasi-64bit application wherein all of the core functionality is running on the 64bit core, as the video stream is not really a core function as it is using 3rd party tech. I have successfuly implemented QT technology into a 64bit application without losing any of the 64bit functionality. The 32bit stuff just doesn't get to use the extra addressing that the core app uses. As I stated in my post above, 64bit addressing would mainly improve encryption/decryption speed, transparency, anything to do with BitBlt (lots of vid stuff I know, but mostly mathematical junk and loops for the drawing), load times, and those "you need a fast cpu" features.

[wagnerr52]

64-bit computing has absolutely nothing to do with multicore/multiprocessor/multithreaded computing. The CRAY X1 is a vector machine, which is a wholly different beast. Imagine trying to run Trillian on one of the SPEs on a Cell.

64-bit computing only gets you one thing, better efficiency on double precision calculations. Consider the example of doing a basic double precision multiply. The 64-bit computer performs a single operation using, and is done. The 32-bit computer must split each number in half, multiply each pair, and then sum the results. Thats six operations, not including anything that has to be done to prevent truncation. Science people are about the only people who care about and need double precision, and even then it's still often unneeded for our use. We have a 700 machine cluster at work and theres only one guy running double precision code. Sure, your encryption can be recompiled to better handle the 256-bit blowfish used by Trillian, but were talking about text, on the order of bytes per second. The improvement would hardly be noticeable by benchmark tools, much less the end user.

Now what else does 64-bit computing get you? It gets you a brand new architecture, free from limitations of x86. That means more and larger register space to do whatever you want. This is where the performance increases that you're talking about come into play. It's effectively like adding more cache to the system. But like any new architecture, you have to program for it, meaning CS would have to maintain two distinct code trees. A lot of code would be transferable, but then a lot of code wouldn't. Quicktime (for Windows) is 32-bit. I don't know how much processing Trillian actually does internally on video to know how much advantage running that stuff in 64-bit mode would get you.

You mention using 64-bit VLC as an alternative to 32-bit Quicktime. Again, I don't know if VLC has been optimized for 64-bit, or how easy (or possible) it is to tap into shared libraries. However such a move would be beneficial for both 64-bit and 32-bit, because IMO, Quicktime sucks ass.

[aemulus]

The amount of mathematical computations involved in Trillian, whether it is something simple such as handling an array of words (could benefit from the extra address space, and CPU core enhancements like SSE3, etc), or something more complex as in encrypted text being encrypted according to the protocol specs (Yahoo, MSN, etc) to be transmitted. That alone would handle be an improvement. And if you have ever looked at assembler code, you would understand that 64bit has even further benefit than you may realize with inane functions such as plotting and calculating pixels in a standard GDI function for drawing an image on the screen. The video card does handle this, true, however, EVERYTHING must first be processed by the main CPU, unless using Overlay which skips a few CPU calls, and instead makes those calls direct to the video CPU. I am pretty sure that Trillian, as great as it is, is not wasting it's time making Overlay calls to display it's skin and emotes for your viewing pleasure. Even transparency would improve in speed, as the image is first drawn as a non-transparency, then an alpha blend (pure mathematical calculations) is applied to give it that transparent look.

Essentially what I am getting at, is programming at the most basic level is pure mathematics, and since 64bit processing allows for more calculations to be done simultaneously, improvement would definitely be noticeable. I am not sure about you, but when I have Trillian running, even though I have lots of fast memory, I would prefer it not to use as much as memory will always be slower than the CPU. Here is how memory works, and why it is slow::

I will use notepad as an example for simplicity:

Open Notepad
1. System calls send program header through cpu after making an internal check to validate that the header is an executable.
2. CPU then executes it's internal exec code and the system files monitors this process by constantly examining your memory registers (or even worse, your swap file)
3. Another call is then made from the system to begin drawing on the screen, and to handle this using your video card. Your cpu then checks the information, and the code is the converted into whichever language your video card manufacturer requires. Your video card then handles each draw process as it is passed through in this loop until you see the notepad "window" on your screen.

Anyway.... you are starting to get the idea that there is a lot more involved where the cpu processing is concerned that could be taken advantage of. If for example, Notepad is in 64bit (lets just assume it is a high usage application like Trillian), then the CPU will handle at least 2 times as much information and therefore process closely to 2 times as fast. Rather than bottlenecking at 1/2 your cpu's ability, while the cpu waits for an additional 32 bits of information to be passed through using the above procedures.

There are a lot more steps involved before, during and after the steps I have mentioned. This was just to give you an idea on WHY 64bit processing is better, and WHY it was invented in the first place. What is the point of having 64bit processing, if all my apps are 32bit ?

[wagnerr52]

There are other optimizations that came with the x86-64 architecture, but single precision performance has not changed. Both modes perform the same number of operations per second, and both perform single precision operations without abstraction. Very little of what Trillian does could be improved by double precision operation.

[Zoomer]

Actually, I would think that eliminating WoW32 would be a rather significant benefit.

64 bit (well, technically only 48 bit now, but I digress) address space? Longs? Remember this is a IM program. Webcam resolutions are typically QVGA or VGA. Any old processor can easily do it.

Nice compression would be to look at x264's codebase. I'm sure coreAVC or ffdshow's stuff might be useful as well, if it can be used as an external library.

[Akkeresu]

Here's a reason to switch to 64-bit.

32-bit will not always be around.

Sure, we can say "Oh, there will always be someone with an old computer" but with all new processors being 64-bit, eventually, 64 bit will be the standard, and 32-bit will be a thing of the past, only supported by emulation modes within OS'es, which will also become 64 bit standard.

Begin development now, and you will have a jump start when the 64-bit software wave hits as the first, fully featured, full 64-bit, multi-protocol IM program. Start too late, and this program may not always be around.

~Akkeresu

[aemulus]

Here's a reason to switch to 64-bit.

32-bit will not always be around.

Sure, we can say "Oh, there will always be someone with an old computer" but with all new processors being 64-bit, eventually, 64 bit will be the standard, and 32-bit will be a thing of the past, only supported by emulation modes within OS'es, which will also become 64 bit standard.

Begin development now, and you will have a jump start when the 64-bit software wave hits as the first, fully featured, full 64-bit, multi-protocol IM program. Start too late, and this program may not always be around.

~Akkeresu

I agree!!

I think the main reason of the argument is that every 64bit processor has 32bit support, even the X64 OS's have 32bit backwards emulation, except of course Linux, x64 = 64!!! Period!!! Meaning if you are a Linux user, unless you want to run some Wonky Emulator and install all 32bit crap into it, then you are SOL if you want to use 64 as your base kernel.

32bit = 1996-2003
64bit = 2003+ (and growing support... not many places to buy a pure 32bit processor anymore)

Soon, there will be no more support for 32bit in Windows Based OS's as well. Microsoft has only implemented 32bit support in all their x64 OS's at the moment for this simple stubborn attitude to switch and make a 64bit edition of any particular application. It is most annoying when you have

"Program Files" and "Program Files (x86)" and the majority of all applications go into.... guess....

There are a lot more OS based optimizations such as advanced memory addressing routines. What happens when you run a whole whack of 32bit apps on a 64bit processor with 32GB of mem.... I can tell you... You run out of memory, even though you have only used what ... 4gb ?... bah!!

IF there is any single reason, it would be so that people can USE their shiny new 64bit machine for what it can do, NOT for what their ancient pure 16bit or 32bit system can do.

Here is what 64bit does over 32bit.... and not talking about CPU's that say 64bit and use an emulation layer like *ntels early release when *MD had already cracked the 64bit barrier.

http://www.pcworld.com/article/id,111508-page,1/article.html

---------------

* Full support for 64-bit integers: All general-purpose registers (GPRs) are expanded from 32 bits to 64 bits, and all arithmetic and logical operations, memory-to-register and register-to-memory operations, etc., are now directly supported for 64-bit integers. Pushes and pops on the stack are always in eight-byte strides, and pointers are eight bytes wide.

* Additional registers: In addition to increasing the size of the general-purpose registers, the number of named general-purpose registers is increased from eight (i.e. eax,ebx,ecx,edx,ebp,esp,esi,edi) in x86-32 to 16. It is therefore possible to keep more local variables in registers rather than on the stack, and to let registers hold frequently accessed constants; arguments for small and fast subroutines may also be passed in registers to a greater extent. However, AMD64 still has fewer registers than many common RISC processors (which typically have 32–64 registers) or VLIW-like machines such as the IA-64 (which has 128 registers).

* Additional XMM (SSE) registers: Similarly, the number of 128-bit XMM registers (used for Streaming SIMD instructions) is also increased from 8 to 16.

* Larger virtual address space: Current processor models implementing the AMD64 architecture can address up to 256 tebibytes of virtual address space (248 bytes). This limit can be raised in future implementations to 16 exbibytes (264 bytes). This is compared to just 4 gibibytes for 32-bit x86. This means that very large files can be operated on by mapping the entire file into the process' address space (which is generally faster than working with file read/write calls), rather than having to map regions of the file into and out of the address space.

* Larger physical address space: Current implementations of the AMD64 architecture can address up to 1 tebibyte of RAM (240 bytes); the architecture permits extending this to 4 pebibytes (252 bytes) in the future (limited by the page table entry format). In legacy mode, Physical Address Extension (PAE) is supported, as it is on most current 32-bit x86 processors, allowing access to a maximum of 64 gibibytes.

* Instruction pointer relative data access: Instructions can now reference data relative to the instruction pointer (RIP register). This makes position independent code, as is often used in shared libraries and code loaded at run time, more efficient.

* SSE instructions: The original AMD64 architecture adopted Intel's SSE and SSE2 as core instructions. SSE3 instructions were added in April 2005. SSE2 replaces the x87 instruction set's IEEE 80-bit precision, with the choice of either IEEE 32-bit or 64-bit floating-point mathematics. This provides floating-point operations compatible with many other modern CPUs. The SSE and SSE2 instructions have also been extended to support the eight new XMM registers. SSE and SSE2 are available in 32-bit mode in modern x86 processors; however, if they're used in 32-bit programs, those programs will only work on systems with processors that support them. This is not an issue in 64-bit programs, as all processors that support AMD64 support SSE and SSE2, so using SSE and SSE2 instructions instead of x87 instructions does not reduce the set of machines on which the programs will run. Since SSE and SSE2 are generally faster than, and duplicate most of the features of, the traditional x87 instructions, MMX, and 3DNow!, the latter are redundant under AMD64.

* No-Execute bit: The “NX” bit (bit 63 of the page table entry) allows the operating system to specify which pages of virtual address space can contain executable code and which cannot. An attempt to execute code from a page tagged "no execute" will result in a memory access violation, similar to an attempt to write to a read-only page. This should make it more difficult for malicious code to take control of the system via "buffer overrun" or "unchecked buffer" attacks. A similar feature has been available on x86 processors since the 80286 as an attribute of segment descriptors; however, this works only on an entire segment at a time. Segmented addressing has long been considered an obsolete mode of operation, and all current PC operating systems in effect bypass it, setting all segments to a base address of 0 and a size of 4 GiB. AMD was the first x86-family vendor to support no-execute in linear addressing mode. The feature is also available in legacy mode on AMD64 processors, and recent Intel x86 processors, when PAE is used.

* Removal of older features: A number of "system programming" features of the x86 architecture are not used in modern operating systems and are not available on AMD64 in long (64-bit and compatibility) mode. These include segmented addressing (although the FS and GS segments were retained in vestigial form for compatibility with Windows code)[3], the task state switch mechanism, and Virtual-8086 mode. These features do of course remain fully implemented in "legacy mode," thus permitting these processors to run 32-bit and 16-bit operating systems without modification.

Virtual address space details

Although virtual addresses are 64 bits wide in 64-bit mode, current implementations (and any chips known to be in the planning stages) do not allow the entire virtual address space of 264 bytes (16 exbibytes, or about 18×1018 bytes) to be used. Most operating systems and applications will not need such a large address space for the foreseeable future (for example, Windows implementations for AMD64 are only populating 16 tebibytes, or 44 bits' worth), so supporting such wide virtual addresses would simply increase the complexity and cost of address translation with no real benefit. AMD therefore decided that, in the first implementations of the architecture, only the least significant 48 bits of a virtual address would actually be used in address translation (page table lookup). However, bits 48 through 63 of any virtual address must be copies of bit 47 (in a manner akin to sign extension), or the processor will raise an exception. Addresses complying with this rule are referred to as "canonical form." Canonical form addresses run from 0 through 00007FFF`FFFFFFFF, and from FFFF8000`00000000 through FFFFFFFF`FFFFFFFF, for a total of 248 bytes or 256 tebibytes of usable virtual address space.

This "quirk" allows an important feature for later scalability to true 64-bit addressing: many operating systems (including, but not limited to, the Windows NT family) take the higher-addressed half of the address space (named kernel space) for themselves and leave the lower-addressed half (user space) for application code, user mode stacks, heaps, and other data regions. The "canonical address" design ensures that every AMD64 compliant implementation has, in effect, two memory halves: the lower half starts at 00000000`00000000 and "grows upwards" as more virtual address bits become available, while the higher half is "docked" to the top of the address space and grows downwards. Also, fixing the contents of the unused address bits prevents their use by operating system as flags, privilege markers, etc., which could become problematic when the architecture is indeed extended to 52, 56, 60 and 64 bits.

The 64-bit addressing mode ("long mode") is a superset of Physical Address Extensions (PAE); because of this, page sizes may be either 4 KiB (212 bytes), 2 MiB (221 bytes), or 1 GiB (230 bytes). However, rather than the three-level page table system used by systems in PAE mode, systems running in long mode use four levels of page table: PAE's Page-Directory Pointer Table is extended from 4 entries to 512, and an additional Page-Map Level 4 Table is added, containing 512 entries in 48-bit implementations. In implementations supporting larger virtual addresses, this latter table would either grow to accommodate sufficient entries to describe the entire address range, up to a theoretical maximum of 33,554,432 entries for a 64-bit implementation, or be over ranked by a new mapping level, such as a PML5. Either way, a full mapping hierarchy of 4 KiB pages for the whole 48-bit space would take a bit more than 512 GiB of RAM (about 0.196% of the 256 TiB virtual space).

Long mode
The architecture's intended primary mode of operation; it is a combination of the processor's native 64-bit mode and a combined 32-bit and 16-bit compatibility mode. It is used by 64-bit operating systems. Under a 64-bit operating system, 64-bit, 32-bit and 16-bit (or 80286) protected mode applications may be supported.

Since the basic instruction set is the same, there is no major performance penalty for executing x86 code. This is unlike Intel's IA-64, where differences in the underlying ISA means that running 32-bit code is like using an entirely different processor. However, on AMD64, 32-bit x86 applications may still benefit from a 64-bit recompile, due to the additional registers in 64-bit code, which a high-level compiler can use for optimization.

Legacy mode
The mode used by 16-bit (protected mode or real mode) and 32-bit operating systems. In this mode, the processor acts just like an x86 processor, and only 16-bit or 32-bit code can be executed. 64-bit programs will not run.

[aemulus]

I can simplify all of the above by saying the following::

Trillian would run faster, less crashes, and more stable!!! If you don't understand why, read the above. Any 64bit native application will benefit over a 32bit app.

Consider: Would you use an 8bit App on your 32bit OS ? Realistically? Would it even work anymore?!

[wagnerr52]

Unless you specifically optimize your program to use the additional register space (or otherwise currently use doubles with a compatibility layer), your program will run SLOWER on a 64-bit architecture. Your integer and pointers are now natively 64-bit, so you have to access double the data from memory. Granted, this deficit is marginal at best, but it still exists. Also, your binary is larger, and you consume more memory.

There is no inherent difference in stability whatsoever. The only way a difference would exist would be if you had a buggy compiler, or buggy hardware.

64-bit Linux has absolutely no problem running 32-bit code. Most pre-packaged distros have two library directories, one for 32-bit modules and one for 64-bit modules. Windows 95 all the way through ME were still 16-bit. They ran 32-bit applications, and had access to 4GB of memory, but they still booted from 16-bit DOS. Windows only recently removed 16-bit operation with the X64 varieties.

I'm not saying Trillian should never be made 64-bit. Like you said, it will eventually have to, however there are a number of higher priorities than having to write and support a new branch. I believe it is a small fraction of users on here running a 64-bit OS, and I think it's a safe bet that there are a good third of Trillian users still running 32-bit processors. Besides, what percentage of programs do you use that are actually 64-bit. I currently have two machines fully 64-bit (FreeBSD and Linux), and my desktop has been running 64-bit Windows since early 2006. My browser, email, text editor, multimedia (viewing and editing), office programs, mapping, most games, tools... are all 32-bit. About the only 64-bit code I have are drivers, PuTTY, and Half-Life.

[DiamondNRG]

I can simplify all of the above by saying the following::

Trillian would run faster, less crashes, and more stable!!! If you don't understand why, read the above. Any 64bit native application will benefit over a 32bit app.

Consider: Would you use an 8bit App on your 32bit OS ? Realistically? Would it even work anymore?!

I think the reason it is all in the 32bit PF folder is because the real world doesn't need 64 bit stuff yet. You are just mad because you spent all that money on 64 bit stuff and feel like you are wasting it.

Well you are. Congrats. That is what you get with new technology. And by the time all the software is 64 bit, they will be pushing the 128bit hardware. This is the way the world works man.

Trillian would not benefit at all from being changed to 64bit. Not one bit. It is an IM client, it doesn't get leaps and hurdles faster.

[aemulus]

Unless you specifically optimize your program to use the additional register space (or otherwise currently use doubles with a compatibility layer), your program will run SLOWER on a 64-bit architecture. Your integer and pointers are now natively 64-bit, so you have to access double the data from memory. Granted, this deficit is marginal at best, but it still exists. Also, your binary is larger, and you consume more memory.

There is no inherent difference in stability whatsoever. The only way a difference would exist would be if you had a buggy compiler, or buggy hardware.

64-bit Linux has absolutely no problem running 32-bit code. Most pre-packaged distros have two library directories, one for 32-bit modules and one for 64-bit modules. Windows 95 all the way through ME were still 16-bit. They ran 32-bit applications, and had access to 4GB of memory, but they still booted from 16-bit DOS. Windows only recently removed 16-bit operation with the X64 varieties.

I'm not saying Trillian should never be made 64-bit. Like you said, it will eventually have to, however there are a number of higher priorities than having to write and support a new branch. I believe it is a small fraction of users on here running a 64-bit OS, and I think it's a safe bet that there are a good third of Trillian users still running 32-bit processors. Besides, what percentage of programs do you use that are actually 64-bit. I currently have two machines fully 64-bit (FreeBSD and Linux), and my desktop has been running 64-bit Windows since early 2006. My browser, email, text editor, multimedia (viewing and editing), office programs, mapping, most games, tools... are all 32-bit. About the only 64-bit code I have are drivers, PuTTY, and Half-Life.

A list of x64 programs I use ?... lol... here you go friend.... Some people have caught on to the idea that advancement in technology isn't just a HARDWARE thing.

Alcohol 120%
UltraMon
Internet Explorer (with Flash... omfg... they finally made an updated 64bit version)
Mozilla
Apache 2.2
MySQL 5.1
Bind (now why would they make an x64 edition... it's only text strings... following your argument... haha)
A plethora of Games written for x64... it's just a game... why does that NEED to be 64... same argument you pose... only text bits going back and forth over an IP protocol for online gaming, and *ahem*... no real performance increase....

gimme a break... only poorly written code (aka... coders who are stuck in the 32bit or earlier mindset) creates programs that are slower on x64. EXE's are typically a bit larger for the x64 core as they are utilizing the additional instruction set, which is completely different from the x32 core. Some of them are even written to run on BOTH x64, and x32 platforms by modifying the PE header instructions.... Look at the assembly headers and you can understand... but those programs also run slower as there is an additional check for each function basically asking "am i running on x64".

If you can seriously sit there with and claim any expertise in technology, and tell everyone on this board that Trillian can't benefit from x64 technology with a straight face, then I will drop this as you will have proven the utter hopelessness of the future of technology, and that no more advances will be made from this point forward with regards to performance.

Cheers.

[wagnerr52]

I consider Alcohol 120% and UltraMon drivers. They access system libraries that require them to be 64-bit.

I just checked the Adobe site, and I still don't see a 64-bit flash player available.

I run my server applications on a dedicated server rather than my Windows desktop. Apache and MySQL could foreseeably use over the 2-3GB of memory limit of 32-bit applications. I don't see any reason for BIND to be 64-bit other than 'because they can'.

Half-life 2 (and friends) is 64-bit. Far Cry had a 64-bit upgrade. Those are the only two I have. I think Crysis might be 64-bit. Newer games are reaching the default 2GB memory limit on Windows, but you can increase that to 3GB. Other than that, games are nearly all floating point math, which is already 64-bit even on 32-bit processors. There may be some performance increase from the increased integer and SSE registers.

Check out any benchmarks comparing 32-bit vs. 64-bit performance, and you'll be disappointed. ExtremeTech did one earlier this month and CineBench was the only program with a notable increase (~12%). Cryptography is about the only thing I've seen with a large boost in performance. Hardly anything else uses large integer math.

[aemulus]

I consider Alcohol 120% and UltraMon drivers. They access system libraries that require them to be 64-bit.

I just checked the Adobe site, and I still don't see a 64-bit flash player available.

I run my server applications on a dedicated server rather than my Windows desktop. Apache and MySQL could foreseeably use over the 2-3GB of memory limit of 32-bit applications. I don't see any reason for BIND to be 64-bit other than 'because they can'.

Half-life 2 (and friends) is 64-bit. Far Cry had a 64-bit upgrade. Those are the only two I have. I think Crysis might be 64-bit. Newer games are reaching the default 2GB memory limit on Windows, but you can increase that to 3GB. Other than that, games are nearly all floating point math, which is already 64-bit even on 32-bit processors. There may be some performance increase from the increased integer and SSE registers.

Check out any benchmarks comparing 32-bit vs. 64-bit performance, and you'll be disappointed. ExtremeTech did one earlier this month and CineBench was the only program with a notable increase (~12%). Cryptography is about the only thing I've seen with a large boost in performance. Hardly anything else uses large integer math.

If you have looked at ANY of the protocols in use for Trillian, almost all information is encrypted and decrypted for each and every message sent / received from the respective protocols. By definition, Trillian mostly deals with cryptography, and gives a nice pretty interface to all protocols such as MSN / ICQ / Yahoo! / AIM, etc as you are aware of this.

Adobe has a 64bit flash in beta... not really released... I am just happy that it's under development.

My main argument isn't to have a 64bit Trillian app just because it is possible, but because there would be a lot of core performance increases (anything that deals with multiple permutations of mathematical algorithms such as the cryptography involved in sending / receiving those pretty text messages you may take for granted).

90% of all applications are purely mathematical based. People are not porting their applications to 64bit for the fun of it. And I am not requesting this be made 64bit for the fun of it. The graphical interface would improve in speed for such things as alpha transparency (a pure mathematical permutation). 64bit indexing for the dictionary would provide for faster lookup as the entire dictionary can be cached in memory. The program would be more stable because it has less potential to conflict in memory with another 32bit application which is also limited to the bottom 2-4gb of memory.

In fact, this whole argument that 32bit is all we will ever need for Trillian, is as asinine as the argument "You will never need more than 640k base memory".

[aemulus]

I think the reason it is all in the 32bit PF folder is because the real world doesn't need 64 bit stuff yet. You are just mad because you spent all that money on 64 bit stuff and feel like you are wasting it.

Well you are. Congrats. That is what you get with new technology. And by the time all the software is 64 bit, they will be pushing the 128bit hardware. This is the way the world works man.

Trillian would not benefit at all from being changed to 64bit. Not one bit. It is an IM client, it doesn't get leaps and hurdles faster.

The REAL reason why there are two folders is for compatibility as Microsoft realized that there are a lot of stubborn developers either unwilling, or incapable to unleash the true power of the hardware available today. (With the exception of Super Computing such as the Cray X1E)

[DiamondNRG]

Right, I was pointing out why the 32 bit one is still the most used of the 2.

[aemulus]

Right, I was pointing out why the 32 bit one is still the most used of the 2.

The answer is simple.

Laziness. Microsoft has made the x64 functions so easy to convert your project. For example, instead of declaring system32 functions, declare system64. Instead of int, use int64 ... like I said.... pure laziness. 32bit is history, so developers should get over themselves, and move on. If my word processing application can be 64bit (and the sole benefit would be increased text size, and loading into memory times (as it takes bigger chunks)), then why can't something more complex such as Trillian which could benefit much more with the encryption stuff, loading history, video, etc. Do you have any idea on how much information is encrypted/decrypted over the various protocols when connecting 6 msn clients, 2 aim, 1 icq, etc etc.... consisting of over 1000 contacts. Do the math... unhorse the power of x64, and you WILL see improvements ... even simply in the startup.

I have to admit, I am growing increasingly tired of the software industry keeping technology at a standstill, using ridiculous arguments like the famous "You will never need more than 640k". Software bashing hardware simply because they are too lazy to implement the new STANDARD, or because they don't know how, so the argument persists with "You don't need that" or "It won't improve anything". Well answer this, if it doesn't improve anything, why is it flagged as a breakthrough. Or why is it even available. I am sure many x64 people have noted serious improvements in areas such as using more programs at a time, etc etc.

Why does every developer seem to believe their application is the ONLY application on the PC ? It's NOT!!! 64bit isn't something new on the table, it has been available to the consumer for over 4 years now, and still.... certain applications seem to take their sweet time -- if ever to implement the enhancements. 64bit comes with new instructions, memory speed enhancements, etc etc. Intel sees it, AMD sees it, Microsoft sees it, even Linux sees it (only mentioning the big players), so why don't people get with the times and USE it. IT IS BETTER, FASTER, and all around more WONDERFUL. For developers, and users alike.

I am tired of seeing and hearing about people who can't do something because there isn't an x64 version of x application. When there is a x86 version of something as an alternative, people use it only becuase they HAVE to... THERE IS NOTHING ELSE --- aka -- TRILLIAN x86 32bit 3.x .... doesn't look as nice as TRILLIAN x64 64bit 4.x ....

What happened to the days when software developers were ahead of hardware. Without the software to use this stuff, hardware improvements will remain at a standstill.

Think of this, why most printers, webcams, etc don't work with Vista x64 ... LAZY DEVELOPERS!!! The hardware works, but the engineers decided to slack off and no make a new driver for the device --- SOFTWARE!!! So because of software, these people need to buy something NEW!! ... Now think, if this trend continues, how likely is it that person will buy a product from that company. Lack of x64 is poor customer support!! And the sick part of this joke is that it isn't all that hard to use M$ API to use the stuff, they already did all the hard work for interfacing with the core, identifying cpu, os, etc. So whats the deal ??

Anyway, I am sick and tired of seeing this kinda crap all over the place giving very poor excuses for their internal lack of skill, and initiative to improve there products. You want x86 .... enjoy... I can probably write my own x64 application faster than waiting on you! I just hate re-inventing the wheel just so my software which by design should support my hardware, yet here we are, hardware is only 1/2 used because of stubborn-ness or perhaps the inbred love for 32bit.

You make me sick! (devil)

[DiamondNRG]

Yup, lets convince them to make it 64bit , that way Astra won't be done until everything else is 128bit.

Whether it is great or not, it is not necessary and your whining is pointless. 32bit is fine for an IM client.