TheSwamp
Code Red => AutoLISP (Vanilla / Visual) => Topic started by: GDF on September 08, 2008, 11:17:25 AM
-
How would I test within a lisp routine to check for 32 vs 64 bit operaring system?
I need to load different arx files based on the test above.
Here are the two files I need to check for:
DOSLib17.arx
DOSLib17x64.arx
(defun ARCH:DOSLIBLOADER ()
(cond ((and (>= (distof (substr (getvar "acadver") 1 4)) 15.0)
(< (distof (substr (getvar "acadver") 1 4)) 16.0))
(if (not (member "doslib2k.arx" (arx)))
(arxload (findfile (strcat ARCH#SUPF "V_15\\doslib2k.arx")))))
((and (>= (distof (substr (getvar "acadver") 1 4)) 16.0)
(< (distof (substr (getvar "acadver") 1 4)) 17.0))
(if (not (member "doslib2004.arx" (arx)))
(arxload (findfile (strcat ARCH#SUPF "V_16\\doslib2004.arx")))))
((and (>= (distof (substr (getvar "acadver") 1 4)) 17.0)
(< (distof (substr (getvar "acadver") 1 4)) 18.0))
(if (not (member "DOSLib17.arx" (arx)))
(arxload (findfile (strcat ARCH#SUPF "V_17\\DOSLib17.arx")))))
((and (>= (distof (substr (getvar "acadver") 1 4)) 18.0)
(< (distof (substr (getvar "acadver") 1 4)) 19.0))
(if (not (member "DOSLib17.arx" (arx)))
(arxload (findfile (strcat ARCH#SUPF "V_18\\DOSLib17.arx")))))
)
(princ))
Gary
-
This isn't necessarily a foolproof method, but you could check for the existance of C:\Program Files(x86) ... on all 64 bit systems, 32bit programs are installed in the C:\Program Files(x36) folder, while 64 bit programs are installed in C:\Program Files
-
Gary,
Not of much, help I know... but
If I remember right, the guys from OpenDCL, have an autolisp function for this....
-
running 32bit
so i can not say for sure but you may try any of these
(vl-registry-read "HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion" "ProductName")
(getenv "PROCESSOR_ARCHITECTURE")
(getenv "OS")
-
Would this not work? [Not Tested]
((and (>= (distof (substr (getvar "acadver") 1 4)) 18.0)
(< (distof (substr (getvar "acadver") 1 4)) 19.0))
(if (not (or (member "DOSLib17.arx" (arx))(member "DOSLib17x64.arx" (arx))))
(or (arxload (findfile (strcat ARCH#SUPF "V_18\\DOSLib17x64.arx")))
(arxload (findfile (strcat ARCH#SUPF "V_18\\DOSLib17.arx"))))))
<edit>
Now that I think about the situation, you may have the file present but not the resource. :oops:
-
VovKa, That is a good push in the right direction ... this should work flawlessly ... returns 32 for 32 bit and 64 for 64 bit
(if (= (getenv "PROCESSOR_ARCHITEW6432") nil)
32
64
)
-
Maybe this will provide you the information needed:
http://through-the-interface.typepad.com/through_the_interface/2007/04/loading_the_rig.html (http://through-the-interface.typepad.com/through_the_interface/2007/04/loading_the_rig.html)
At the bottom you will find a modified arxload function to test between 32 or 64 bit.
MJG
-
Would this not work? [Not Tested]
((and (>= (distof (substr (getvar "acadver") 1 4)) 18.0)
(< (distof (substr (getvar "acadver") 1 4)) 19.0))
(if (not (or (member "DOSLib17.arx" (arx))(member "DOSLib17x64.arx" (arx))))
(or (arxload (findfile (strcat ARCH#SUPF "V_18\\DOSLib17x64.arx")))
(arxload (findfile (strcat ARCH#SUPF "V_18\\DOSLib17.arx"))))))
<edit>
Now that I think about the situation, you may have the file present but not the resource. :oops:
Thanks Alan, this worked.
-
Maybe this will provide you the information needed:
http://through-the-interface.typepad.com/through_the_interface/2007/04/loading_the_rig.html (http://through-the-interface.typepad.com/through_the_interface/2007/04/loading_the_rig.html)
At the bottom you will find a modified arxload function to test between 32 or 64 bit.
MJG
Thanks for the link, I will have to dig into it.
-
Gary, all versions of Windows create environment variables that determine what kind of processor architecture is running. If it is a 64 bit process you will always find PROCESSOR_ARCHITEW6432 in the environment variables, however, it will be nonexistant on 32 bit operating systems, therefore you can readily tell if the OS is running a 64 bit process or 32 bit. All windows will have the environment variable PROCESSOR_ARCHITECTURE, but you would need to verify the value against a set of unknowns.
The mere existance of PROCESSOR_ARCHITEW6432 assures you that you have a 64 bit OS running so the result would be effective.
-
The mere existance of PROCESSOR_ARCHITEW6432 assures you that you have a 64 bit OS running so the result would be effective.
cool Keith™, i'll save it in my "in case of" notes
-
Gary, all versions of Windows create environment variables that determine what kind of processor architecture is running. If it is a 64 bit process you will always find PROCESSOR_ARCHITEW6432 in the environment variables, however, it will be nonexistant on 32 bit operating systems, therefore you can readily tell if the OS is running a 64 bit process or 32 bit. All windows will have the environment variable PROCESSOR_ARCHITECTURE, but you would need to verify the value against a set of unknowns.
The mere existance of PROCESSOR_ARCHITEW6432 assures you that you have a 64 bit OS running so the result would be effective.
Thanks. I am playing around with and testing autocad 2009 on windows xp 64 bit on a backup machine.
So far I think autocad 09 is ___ well lets just say, I think I'll keep on 2008 for a while longer.
-
Do you have the 64 bit version of AutoCAD running? If not then I am not sure you can run the 64bit arx modules.
-
Do you have the 64 bit version of AutoCAD running? If not then I am not sure you can run the 64bit arx modules.
Yes I have 2009 running with all of my customization "arch program" on a 64 bit window xp machine. The DOSLib17x64.arx file loads ok...used CAB's code.
I'm looking for an acetutil.arx 64 bit version.
Everything seems to be running ok, just a very minor glitches.
My first impression is that it takes longer to open drawing files, and I don't like autocads new menu interface.
My goal is to update my "arch program" custom routines to be able to run either a 32 or 64 bit operating system.
Gary
-
Expresstools for 64bit ... hmmm ... might be hard to come by ... will the 32bit modules not load?
-
Expresstools for 64bit ... hmmm ... might be hard to come by ... will the 32bit modules not load?
No.
I have not found a 32 bit arx file that will load.
-
Expresstools for 64bit ... hmmm ... might be hard to come by ... will the 32bit modules not load?
No.
I have not found a 32 bit arx file that will load.
I found the express 64 bit files on the autocad 2009 cd.
And the acetutil.arx file will run on the 64 bit system...and it works with the 32 bit system also. So all I have to do is update all of the express tools routines with the new and I should be good to go.
-
Thanks everyone, I learned some more.
Any old .arx or .dll will need to be updated when going from 32 to 64 bit system.
Got everyhing working, no more glitches...but I am looking for an update on the following .dll file, need a 64 bit version:
AxAcadStatusBarButton.dll
;; Requires AcadStatButton.zip available from ManuSoft at
;; http://www.manusoft.com. See the Readme.txt file for instructions
;; regarding registration of the ActiveX interface. Specifically,
;; the use of AxReg.bat and AxUnReg.bat.
;; Thanks to Owen Wengerd.
;; Note regarding button pressed/not pressed status. Since a reactor
;; is not used to monitor the pickstyle variable, a change to the
;; variable via command line, or Options, or Ctrl-Shift-A will not
;; automatically update the button status. However, the button will
;; correct itself the next time it is picked. By design intent,
;; keep it simple and assume the button will be used in lieu of
;; other methods.
;;Joe Burke
Gary
-
Update:
Gary:
Funny you should ask -- I'm working on it today! Stay tuned, I'll let you
know when it's available. :)
--
Owen Wengerd
President, ManuSoft <http://www.manusoft.com>
VP Americas, CADLock, Inc. <http://www.cadlock.com>
-
Update:
Gary:
Funny you should ask -- I'm working on it today! Stay tuned, I'll let you
know when it's available. :)
--
Owen Wengerd
President, ManuSoft <http://www.manusoft.com>
VP Americas, CADLock, Inc. <http://www.cadlock.com>
Update:
Installed Owen's updated AcadStatButton files which are now available on the ManuSoft web
site. Works perfectly on windows xp 64 and autocad 2009 64 bit.
I'm getting use to autocad 2009 version now....liken it a little better. The 64 bit version seems to working faster.
Gary
-
I may be a few days late for this, but this is how I set up my Doslib to load the proper version:
(if (and (vl-file-directory-p "C:\\Program Files (x86)") (= (ver) "Visual LISP 2009 (en)"))
(arxload (strcat proglocationc "DOSLib 7.8\\DOSLib17x64.arx"))
(arxload (strcat proglocationc "DOSLib 7.8\\DOSLib17.arx"))
)Mine is mostly set up that way because I am running 32 bit AutoCAD 2008 on a 64 bit os, while also running 64bit AutoCAD 2009 on the same OS. I needed to have some sort of a way to delineate between the two programs. You cant just assume that you are running 64 bit AutoCAD just because the OS is 64bit.
-
Thanks Chris
I like the 2 tests.
Gary
-
Thanks Chris
I like the 2 tests.
Gary
yes, the two tests are good, but it is kind of unique for my situation, there has to be a way to tell from AutoCAD what version it is, wait there is, check the support path, if the path for the program itself is Program Files and there is a Program Files (x86) folder, than you know it is 64 bit. If the path is Program Files (x86) then it has to be 32 operating on a 64 bit os, and if it is in Program Files and there is no Program Files (x86) it is 32 bit on a 32 bit system. I thought there is a system variable somewhere, by I cant find it right now.
-
Another method of checking for 64-bit from my toolbox:
(defun Acad64Bit-p ()
(vl-load-com)
(> (strlen (vl-prin1-to-string (vlax-get-acad-object))) 40)
)
; If this doesn't work, use (GETENV "PROCESSOR_ARCHITECTURE") to get the Windows Environment variable for the plaform:
; x86 = 32 bit
; x64 = 64 bit
; (wcmatch (getenv "PROCESSOR_ARCHITECTURE") "*64*")
-
Thanks Crank, works perfectly.
Gary
-
resurrected from the tombs.
assuming the arx is set to demand load (default install), what happens when you issue this ?
(command "DosLib")
don't have the means to check it ....
-
Here is what I have been using for just this reason:
I first define a routine to test it:
(defun Acad64Bit-version ()
(vl-load-com)
(> (strlen (vl-prin1-to-string (vlax-get-acad-object))) 40)
)
Then I load the .arx files as needed based on the test:
(if (= (acad64bit-version) T)
(progn
(arxload "MdiTab18-x64.arx")
(arxload "DOSLib18x64.arx")
(arxload "OpenDCL.x64.18.arx")
)
(progn
(arxload "MdiTab18-32.arx")
(arxload "doslib18.arx")
(arxload "OpenDCL.18.arx")
)
)
I know I got the original code from somewhere, but I am honestly not sure where, anyway, this has worked fine on every system here so far.
-
Speaking of ...
I gotta buy a new CADD machine (just resigned from my job / venturing out on my own) ... should I go 32/64?
Before you answer, I frequently process drawings that are produced by, or reference, (third party) verticals, like AutoPlant, MultiSuite etc. Are there a lot of issues with object enablers going the 64 bit route?
Sage advice welcome, I'm a O/S & hardware moron.
-
Speaking of ...
I gotta buy a new CADD machine (just resigned from my job / venturing out on my own) ... should I go 32/64?
Before you answer, I frequently process drawings that are produced by, or reference, (third party) verticals, like AutoPlant, MultiSuite etc. Are there a lot of issues with object enablers going the 64 bit route?
Sage advice welcome, I'm a O/S & hardware moron.
tough question. I dont know about object enablers, but 64 does seem more stable. I had to wait for Eagle Point to release a 64 bit version before I could upgrade, and even it is buggier than heck.
-
As for 64-Bit, we are going to be completely 64-Bit vs. 32-Bit by the end of the year, we do keep one spare station that is a 32-Bit system for compatibility (there is getting to be less and less of a need for it though and never for AutoCAD related items).
64-Bit runs CAD a bit faster, but is almost a requirement for Revit (something to think about for the future).
-
Speaking of ...
I gotta buy a new CADD machine (just resigned from my job / venturing out on my own) ... should I go 32/64?
Before you answer, I frequently process drawings that are produced by, or reference, (third party) verticals, like AutoPlant, MultiSuite etc. Are there a lot of issues with object enablers going the 64 bit route?
Sage advice welcome, I'm a O/S & hardware moron.
Don't know anything about MultiSuite, but ProStructures (formerly a.k.a. AutoPlant Structural) is now available as 64 bit.
Ass-u-me 64 bit OE is available.
If you can't find it on Bentley.com, drop your regional engineer a line..
I am on 32 bit, so no personal experience.
-
I haven't the foggiest idea about Object Enabler(s) however;
Intel Core i7 2.8ghz
8 gb ram
Windows 7 x64 OS
I have AutoCAD MEP 08 (08 is only 32 bit) installed and working just fine. I had to tweak the ACAD.MSI with ORCA [ http://msdn.microsoft.com/en-us/library/aa370557%28VS.85%29.aspx ] a bit to get ACAD to install but after that the tweaking was very minimal. This leads me to my opinion on the situation; If you are purchasing a new PC then i don't feel you will have a problem because IMO win7 seems to handle the "older stuff" very well (I just installed Visual Basic 5.0 for maintenance i need to do on some old crappy app) and windows didn't even blink an eye.
I think you'll be fine with x64.