Forums Bug Reports $bits identifier

Not sure if this is a bug or not.

The $bits identifier has existed since early in the mirc 5.x versions, and answered 16 or 32 to indicate whether it was running the 16bit or 32bit variant of mirc.

Is there any intention to have $bits report whether mirc is using the 32 or 64bit version of Vista or Win7?

As of 7.22, $bits still returns 32 always.

Although you may be running a 64-bit OS, the mIRC application is still only a 32-bit application. The intention of the $bits identifier is to tell you which version of the application you are using, not what your OS supports.

There really aren't any compelling reasons to rewrite mIRC as a 64-bit application (and there are even some disadvantages), so I doubt there are any plans to rewrite mIRC as a 64-bit application at this point in time.

Not a bug. mIRC is a 32bit executable as pointed out above. Eventually mIRC was released as a 32bit executable-- and eventually mIRC will be released as a 64bit executable, but that probably won't happen any time soon. The difference with the 16/32 issue is that back in the day there were no 16bit emulation layers on 32bit platforms, so mIRC had to be released in two different executables. These days there is no point in releasing a 64bit version until 32bit machines are all gone and support for the compat layer in the hardware architecture is dropped. Again, that probably won't happen for quite a while.

ok thanks, i was mis-understanding what the $bits was telling us, since $os just says Vista or Win7 without indicating whether it's Vista-32 or Vista-64.

I'm guessing the best way to see if someone has 64-bit is to see if $isfile(c:\windows\system32\command.com) is $false?

The "proper" way seems to be described in http://stackoverflow.com/questions/601089/detect-whether-current-windows-version-is-32-bit-or-64-bit

A little script would be:



Note: on my 64bit system this value returns 2h, not 40h, for some reason. I can't tell if this is just a broken registry or the same for other systems. You could add $iif($base(%value,16,10) == 32,32,64) to the result to ensure that it only returns 32/64.

But yes, there are probably a lot of other hacks that can be fairly reliable-- another would be checking for a "C:\Program Files (x86)\" folder, which would indicate a 64bit machine.

https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/230779/page/2

See FroggieDaFrog's first comment and the comment following it, should do the job, even for you

The code I posted does the job, "even for me". But yes, that is another way to do it. There are many.

Your code simply doesn't work on my 64bits system..

nor does it work on mine, for some reason

Tested the code here, dont work on win 7 32 bits ultimate.

;---- edit

Grapic drivers do use the same bits as your system, so why not grab the bits from there?

//echo -a $wmiget(Win32_VideoController).currentbitsperpixel

You dont install 32 bit drivers on a 64 bit system. Just a idea.

It's not a problem with the code, which in itself is fine, it's just that we don't have that entry in our registry, that's why I suggested the other way, it seems much more reliable

I haven't done much with drivers in COM, but I know that graphics information in COM is often sketchy. Sometimes it's there and sometimes it isn't, depending on the card. If the driver information isn't always available, then it's probably not the best option. I'd stick to using the OS Architecture (as mentioned in the link Wims posted above) as long as this isn't going to be used on an old system where that property isn't available.

Also, that property sounds like it's the color depth and not the driver architecture. If that's the case, most people are using 32bit color depth and that isn't related to your OS architecture. If it really is the driver architecture, then ignore this part, but the first paragraph still stands.

Btw, this is what Invision uses. I got help with it a couple years ago on these forums and adjusted it some since then. It takes a 3rd value that lets you obtain details when more than one item is present.



For example, if I wanted to check my drives, I probably wouldn't want just the first controller. So, with this, I can do:

//echo -a $isystem(DiskDrive,Caption,1)
//echo -a $isystem(DiskDrive,Caption,2)
//echo -a $isystem(DiskDrive,Caption,3)

And the output would be:
Maxtor 6L300R0 ATA Device
ST3500630AS ATA Device
WDC WD1001FALS-00J7B0 ATA Device

Of course, I probably wouldn't be interested in that information, but that's just an example. You can use a loop to get all of the information if needed and using 0 as the third parameter will tell you how many devices there are.

It is basically the same as was already shown, but I wanted to show how to make use of the third parameter.

*Note: This automatically fills in Win32_, so you don't need to specify that when using it. However, if you want to access any COM object other than the Win32_ ones, you'll need to remove that from the script and then include it in the parameter instead.

Using:

You *should* be able to use:

which should return: "64" for 64bit machines, or "32" for all others.

I'd be curious to know what version of Windows you're running. I'm testing this on Win7. It might be specific to that.

I'm also using windows 7, but the information your script is retieving seems to be related to the processor

Windows 7 32bit here and no Platform ID in my registry either. Besides, that's the processor and not necessarily the OS like Wims mentioned. I wouldn't want to use the registry for it anyhow. 64 and 32 bit registries are different as are other OS registries, so expecting a key to be the same and in the same place if you're distributing your script is probably not a good idea. Certain keys may always be in the same place (Run, for example, though there are multiple Run keys and some of those vary by OS and architecture). But I'm not so sure about hardware keys. If it was always there, then sure, but it looks like it's not always available even on Windows 7.

@Froggie, yes, the OS Architecture property is probably the best option. However, as I mentioned in the thread that was linked above, that property is limited to certain versions of Windows. That may or may not be a problem depending on your needs.

The thing is. only windows vista and later have a 64bit version.
xp and win2k are 32bit, and I seriously doubt anyone is still using a windows version before that. So I saw no need to clutter up code for maybe 0.01% of the people that would need the info for such OSs

Windows XP has 64 bit.

welp. Guess i'll have to make a work around for xp 64bit

$isdir(C:\Program Files (x86))