I haven`t crossed swords with 64 bit systems yet. However the installer installs the DLLs to the SYSTEM folder as reported back by ther OS so it should be getting put in the correct place as far as Windows is concerned. On 32 bit systems this is usually system32 but I know that 64 bit windows does a lot of "hiding" with 32 bit files so that programs still function as they should.

First thing to check is if mwgfx.sdll is working with RS_tools. As far as I know it is used when you need to display visually a tgpcdx file so if you are getting these displayed in the program then it is working.

If it is not working and you have winzip or similar on your system you should actually be able to extract the files from the downloaded exe (which is actually a self-extracting exe zip file)and manually put them wherever you want. However if the installer reported that it was putting them in system32 then that is where windows said it wanted them. If it then redirects this file copying to some other virtual location in order to comply with the way it emulates 32 bit for 32 bit programs then that is what it needed to do.

As far as I know RS_Tools is a 32 bit program so should be running under 32 bit emulation and using the files correctly.

Just done some research on the web and it is interesting

http://blogs.msdn.com/gauravseth/archive/2006/04/26/583963.aspx

64 bit windows keeps track of 32 bit and 64 bit code by putting them in seperate folders. The running programs don`t need to know about this as the system will automatically to the correct folder. Contrary to what seems logical 64 bit dlls go into system32 while 32 bit dlls need to go in syswow64 (I said it wasn`t logical).

My guess is that the mwgfx installer has put the files in syswow64 even though it "thinks" it is putting them in system32

The other thing to note is that you shouldn`t manually put 32 bit dlls into system32 OR manually put 64 bit dlls into syswow64. DLLs in system32 are run in 64 bit mode while dlls in syswow64 are run in "64 bit emulating 32 bit" mode. So in either case if the dll is of the wrong format it will crash or worse

Check syswow64 and see if the files are actually already there.

The confusion is because the system folder really is system32 but when a 32 bit program accesses it (as with my installer) it actually gets silently redirected to syswow64 but still thinks it is looking at system32

Well, three years later one to reply... Indeed, hte dlls arein the Syswow64 directory. What would be a good solution as DXTBmp is not working now.

Thanks,
Menno

The dlls are installed by my home-made installer using the normal Windows API to locate the SYSTEM folder. This will automatically be Syswow64 on 64 bit systems (and system32 on 32 bit systems)
I have several 64 bit systems now and I have had no real problems with any of my programs.
Howe is DXTBmp "not working"? Is it failing to start up at all or is it running but not working as it should?

well, when downloading the dll one cannot choose which version. I cannot choose the 64 bit version. It just downloads a version and I guess it should distinguish which system it is installed to.

Menno

There is only one version.
All my programs are 32 bit but will run perfectly well on 64 bit systems. Windows 7 is designed with full 32 bit compatibility hence the extra "program files (x86)" and syswow64 folders used for holding 32 bit apps/dlls leaving the standard "Program Files" and System32 folders for full 64 bit code

When 32 bit programs are installed on a 64 bit system they need to follow certain guidelines. They shouldn`t be put in "Program Files" (only used for 64 bit applications) and system support files (dlls, ocx, lib, etc)that would go in system32 on 32 bit systems must go in syswow64.
The 64 bit system is intelligent and if an installer or application requests a system path it will return the correct one for the particular program. If a 32 bit program requests the SYSTEM path it will return the path to syswow64. If a 64 bit program requests the SYSTEM path it will get the path to system32. Similar things happen in calls to the registry.
On 32 bit systems 64 bit programs won`t run at all and all paths returned will be the standard ones (Program Files, System32)
As long as a program is written using the official windows api calls rather than assuming any fixed paths it will work ok on either system

I don`t actually have a 64 bit compiler for most of my (now rasther aged) programs. Even if I did there is little advantage in doing 64 bit versions. They might be very slightly faster but the added complication of keeping 2 versions of everything up to date wouldn`t be worth it. And as long as even one of my programs was still available only in 32 bit the 64bit user would need both 64 bit and 32 bit dlls installed.