MUSHclient usability in WinXP64

I'm wondering if MUSHclient uses a 16 bit installer or not, as the upcoming x86-64 WinXP won't run those.

Thanks, have fun :)

It uses the nullsoft installer, which I'm fairly certain is 32bit (yep, just checked to be sure). You can get the version number while installing if you want to check it out. (nsis.sourceforge.net)

However, Nick also provides the tar.gz for wine users, so if nothing else, you'll be able to unzip from that.

Coolness. I'm going to be switching to it asap, so I was just makin sure my bases are covered :)

a native version would rock but it's probably about as likely as...the sky turning puke green and raining chunks...whee!

(I'm not on drugs, I'm just wierd.)

Don't know.. If Nick ever switched from the MFC libraries to something like Cygwin's, then not only might it be possible to compile a 64-bit version, but also, with a few changes, make a Linux version to. Though, it would probably work a tad slower. The priority for GCC and the Cygwin libraries haven't necessarilly been optimization. Besides, doesn't XP64 use two different versions, depending on the processor involved? That would make compiling it even more complicated, since the two processors are not compatible on a machine code level. However, ironically a native Intel64 compile using Cygwin may actually be faster than a 32-bit version running in Intel's emulation of 32-bit. lol On an AMD, that wouldn't be the case, since its native 64-bit also runs native 32-bit.

Definitely one case where Linux has the advantage, since as long as the coder didn't do something really stupid, such as assuming things like 'sizeof(integer)' will always be the same on every machine, damn near everything for it can be installed by compiling it for the processor(s) you are using. Windows stuff... They probably just charge you even more for privalage of you to picking which version you actually need. lol Assuming a 64-bit even exists for the product in the first place. Takes years to track down all those 'sizeof' errors their lazy coders introduced from one end of the source code to the other. ;)

ok you've been confused somewhere along the line

XP64 only has one version, because AMD64 and EM64T are the same thing....formerly x86-64 (x64 from now on)

Both run x64 the same way, whatever they decide to call it.

x64 doesn't support MMX or some other older features, so unfortunately some code just won't work when porting. So 'native 32-bit' isn't really true.

x64 has three modes...legacy mode (32 bit) compatibility mode (32 or 64 bit) and Long mode (64 bit only...) XP64 only uses Long mode.

http://techreport.com/reviews/2005q1/64-bits/index.x?pg=1 <- good new article on it

Rather, it supports MMX and things in legacy mode, of course, and probably compatibility mode also

Hmm. I thought Intel was still making the non-x86 compatible one, but come to think of it I believe I read a while ago that Intel realized it worked badly and licensed AMD's solution, so...

Yeah I was wondering if you were thinking of Itanium...
(sorry, I didn't get another topic reply notification so I assumed you hadn't replied)
Itanium doesn't really count...I don't think it'll ever make the consumer space. It's nowhere near good enough, and I wonder what crack they were smoking when they decided it was a good idea. (Of course, the specs for it were made over ten years ago, so that's probably where...quite a bit longer than ten, I'm sure, but I don't have the numbers in front of me.)

Well... Technically a complete redesign is far better than gluing new extensions on an old set of opcodes. Makes things a damn sight less confusing for compiler developers or people trying to code Assembly for it too, but no one wants to have to abandon everything that still works in order to provide something that would truely blow everyones socks off. Instead, they shackle either emulations into it or add in new layers of complications into the design, so it runs almost as well as a pure 64-bit would, but still runs 32-bit native as well. Neither is the *best* solution, but it keeps the coders from the thousands of companies around making software from all pulling their hair out and making a mess all over the floors. ;) lol

Well, that may be true, but that doesn't mean it was a GOOD redesign. The Cell processor sounds more to my liking.

Have an article (there're plenty around but hell I like this one, I've read them all among many months though so there may have been others i liked just as much) http://techreport.com/reviews/2005q1/64-bits/index.x?pg=1

You can read how app benchmarks look now, how x64 cleans up x86 (additional registers, no x87, MMX, or 3dnow, and other stuff,) and stuff like that