Which one? 64 or 32 bit?

[Ahankhah]

If you don't mind using a 3rd party tool, this is one of the many features of DOSLIB. (function name dos_isacad64)

 

rkmcswain, we have a saying in persian called the story of egg and hen...

The problem of me is finding out the current version of AutoCAD to arxload DosLib##.arx or DosLib##x64.arx.

[Ahankhah]

...There is another method here:

http://www.theswamp.org/index.php?topic=24835.msg367041#msg367041

rkmcswain, a very good site, thanks alot.

[Ahankhah]

(getenv "PROCESSOR_ARCHITECTURE")

 

alanjt, thank you for your guidance, but this returns the hardware specification, not AutoCAD version. You know it is possible to install AutoCAD 32bit on Windows 7 64 bit.

[Ahankhah]

Platform system variable also returns the kind of installed Windows.

 
(getvar 'Platform)

I am searching yet to find a way to discover whether the version of installed AutoCAD is 64 or 32.

[Ahankhah]

As a conclusion to suggested methods:

(defun IsAcad64Bit? ()
   (vl-load-com)
   (and (> (strlen (vl-prin1-to-string (vlax-get-acad-object)))
                                                 ; 64 bit: "> 40"
                                                 ; 32 bit: "< 40"
           40
        )                                        ; AutoCAD check
        (vl-string-search "64"
                          (getenv "PROCESSOR_ARCHITECTURE")
                                                 ; 64 bit: "x64"
                                                 ; 32 bit: "x86"
        )                                        ; Hardware (Processor) check
        (vl-string-search "64"
                          (getvar 'Platform)     ; 32 bit = "Microsoft Windows NT Version 5.1 (x86)"
                                                 ; 64 bit = [b][color=red]? (I don't know. Should any one who knows add to comment?)[/color][/b]
        )                                        ; Software (Operating System) check
   )
)

 

(defun IsAcad32Bit? () (not IsAcad64Bit?))

[irneb]

I think you're on the right track, but going beyond what is necessary. Look at the code here: http://blog.jtbworld.com/2007/04/determine-programmatically-if-autocad.html

 

All you need to do is check with the ACad64bit-version routine, which would return T if 64bit, nil otherwise. You strictly don't need to check if the OS is 64bit with the PROCESSOR_ARCHITECTURE or Platform variables - since if ACad is 64bit it MUST be on a 64bit OS, right? It's just if ACad is 32bit that it might be on either OS.

 

About the AMD64 in the PROCESSOR_ARCHITECTURE registry entry, that's just M$ being lazy as usual. AMD came out with the 1st 64bit CPU (as compared to Intel that is), so M$ then had their OS (I think it was still NT then) read AMD64. They simply didn't update to match intel as well. What they "should" have done is change that to x64 (which should cover both Intel and AMD), but they can't even fix bugs - so why would they do something about such a trivial point?

[Ahankhah]

irneb,

you are right, I just made a list containing codes to check the processor, OS and AutoCAD.

So this code satisfies

(defun IsAcad64Bit? ()
   (vl-load-com)
   (> (strlen (vl-prin1-to-string (vlax-get-acad-object)))
                                                 ; 64 bit: "> 40"
                                                 ; 32 bit: "<= 40"
           40
   )                                             ; AutoCAD check
)

[LibertyOne]

Greetings,

does anyone know how it is possible to find out whether the current version of acad is 32 or 64 bit?

 

Hi Ahankhah,

 

read this --> http://through-the-interface.typepad.com/through_the_interface/2007/04/loading_the_rig.html perhaps it may lead you in the right direction...

 

cheers

[Ahankhah]

Hi Ahankhah,

 

read this --> http://through-the-interface.typepad.com/through_the_interface/2007/04/loading_the_rig.html perhaps it may lead you in the right direction...

 

cheers

Thank you very much LibertyOne,

... but sadly the web address is filtered in Iran!!!!!!!!!!!!!!!!!!!!!!!!!

Could you copy the article into this forum?

[Organic]

Thank you very much LibertyOne,

... but sadly the web address is filtered in Iran!!!!!!!!!!!!!!!!!!!!!!!!!

Could you copy the article into this forum?

 

You could try and access it through Google Cache or a proxy.

 

Loading the right version of an ObjectARX module into 32- or 64-bit AutoCAD

 

This question has come in from a number of developers...

How can I tell when my application is running inside a 64-bit version of AutoCAD?

As mentioned in this previous post, AutoCAD 2008 installs as native 64-bit binaries on a supported 64-bit OS, just as 32-bit binaries get installed on a supported 32-bit OS.

A minor complication is that certain of our AutoCAD-based products do not yet have native 64-bit versions. Our Engineering teams are working on this, but in the meantime, your application might well be working inside a 32-bit Autodesk product on a 64-bit OS.

So how do we know whether we're on a 32- or 64-bit platform (i.e. AutoCAD)?

The ideal would be to have a simple system variable (just like we have ACADVER for the version of AutoCAD), which can be queried from any environment. Unfortunately this has not (as yet) been provided, so we have to look for another approach, for now.

The good news is that .NET applications generally shouldn't care - the same binary will work on both 32- and 64-bit platforms. The same for LISP, but then people often use LISP loaders to load ObjectARX modules - which most certainly do care - so my feeling is that this problem will most commonly be faced from LISP.

Before talking about getting the information from LISP, let's talk a little about ObjectARX, first. ObjectARX modules are built specifically as 32- or 64-bit versions. The version you load will depend on the host executable (the AutoCAD platform) you're working in, not on the OS. A 32-bit module will simply not load in a 64-bit version AutoCAD and vice-versa. The way most professional developers make sure the right version of their module is loaded, is to set up demand-loading keys appropriately from their installers, which AutoCAD uses to locate the appropriate modules and load them.

A module doesn't usually need to know whether it is 32- or 64-bit (and with polymorphic types in ObjectARX you should be able to build both versions off the same source code). That said - you might want to enable certain memory-intensive operations from your 64-bit modules but not from your 32-bit versions (for example), so one way is simply to declare a pointer and check its size (thanks to Gopinath Taget, from our DevTech team in San Rafael, for proposing this solution):

Adesk::IntPtr ptr;

int ptrSize = sizeof( ptr );

If ptrSize is 4, then you're in a 32-bit module - if ptrSize is 8, you're in a 64-bit module.

This could clearly also be exposed as a LISP-callable function (using acedDefun()), which is a solution for people who create their own ObjectARX modules but clearly not viable for people who don't.

So now back to our common scenario of people using LISP to load the correct version of an ObjectARX module: in the absence of a handy system variable, what do we do?

I thought about this for a while, and booted around some strange ideas such as using COM from LISP to query file attributes from AutoCAD binaries (yeech), and eventually decided that the best approach was simply to try to load a module, and if it fails, try a 64-bit specific name.

Here's the technique - you would use this function as a replacement for (arxload "myapp"):

(defun myarxload (fn / fn64)

;(princ (strcat "\nLoading " fn))

(if

(vl-catch-all-error-p

(vl-catch-all-apply 'arxload (list fn))

)

(progn

(setq fn64 (strcat fn "x64"))

;(princ (strcat "\nLoading " fn64))

(if (findfile fn64)

(arxload fn64)

)

)

)

(princ)

)

This code assumes a few things...

 

• We pass in the module name without the extension (as we append "x64" to the filename)
  
• We have used "x64" as a suffix for 64-bit versions of our modules (e.g. "AdskMyAppx64.arx")
  
  • I'm not aware of any convention for this... we simply use the same module names inside AutoCAD (which removes the need for code such as this, in any case)
    

I'd be very interested to hear the experiences and suggestions of readers of this blog on the subject. This topic has come up a few times and perhaps more of you have comments that would help.

 

[irneb]

That basically just uses a work-around by trying to load a 32bit ARX file. If it fails then you know you're using a 64bit version of ACad.

 

I think that's a bit of a fubar method, since you're relying on something to fail. In which case the check for the length of the ActiveX ACad object's representation is a lot less disruptive. Only prob I can see with this is it might work differently if you're using some other vertical version of ACad.

[LibertyOne]

That basically just uses a work-around by trying to load a 32bit ARX file. If it fails then you know you're using a 64bit version of ACad.

 

I think that's a bit of a fubar method, since you're relying on something to fail. In which case the check for the length of the ActiveX ACad object's representation is a lot less disruptive. Only prob I can see with this is it might work differently if you're using some other vertical version of ACad.

 

Not really, the tip from Gopinath Taget allows you to check, just not in AutoLisp or VisualLisp

you might want to enable

certain memory-intensive operations from your 64-bit modules but not from your 32-bit versions (for

example), so one way is simply to declare a pointer and check its size (thanks to Gopinath Taget, from our

DevTech team in San Rafael, for proposing this solution):

Adesk::IntPtr ptr;
int ptrSize = sizeof( ptr );

If ptrSize is 4, then you're in a 32-bit module - if ptrSize is 8, you're in a 64-bit module.

This could clearly also be exposed as a LISP-callable function (using acedDefun()), which is a solution for

people who create their own ObjectARX modules but clearly not viable for people who don't.

[LibertyOne]

AutoCAD32or64bit.pdf

[Ahankhah]

Dink87522, thank you very much.

[Ahankhah]

[ATTACH]27371[/ATTACH]

LibertyOne, thanks alot for your favore:).

[alanjt]

You could just attempt to load until it is successful. I do this at work to account for machine bit or version differences for certain arx files. Just easier than all the crazy checks.

 

((lambda (directory)
  (if (setq directory (findfile directory))
    (vl-some '(lambda (file)
                (not (vl-catch-all-error-p
                       (vl-catch-all-apply 'arxload (list (strcat directory "\\" file)))
                     )
                )
              )
             (vl-directory-files directory "*arx" 1)
    )
  )
)
 "c:\\DosLib"
)

 

eg.

[Ahankhah]

You could just attempt to load until it is successful. I do this at work to account for machine bit or version differences for certain arx files. Just easier than all the crazy checks.

 

alanjt, nice offer and good code, thank you very much.

[alanjt]

alanjt, nice offer and good code, thank you very much.

 

.............