64-bit install

Re: 64-bit install

zride91 — Tue, 01 Dec 2009 01:49:34 GMT

Ah! Thanks again Roy, it was the "/" that I forgot in the variable! Everything looks to be working GREAT now. Since I've got it working, it seems the _USTN_BENTLEYROOT variable also works the same way to accommodate the different locations of installs.

Thanks again all who posted, you've been a big help.

Re: 64-bit install

Bear — Wed, 25 Nov 2009 04:58:46 GMT

You could also create a variable for the IR install location that works with the keyin. In your build cfg files, try creating a '%if exists' that looks for the 64-bit install location and if not exists then use the 32-but location. Not hard to do, let us know how you go?

Re: 64-bit install

Roy Gallier — Wed, 25 Nov 2009 01:00:40 GMT

May have something to do with the "(" &")" which are considered operators. I would try eliminating these from your config variable. Also the "/" after the directory may be a problem:

PROGAMFILESX86 = ${ProgramFiles(x86)}/

$ mdl l "$(PROGRAMFILESX86)Bentley V8i\InRoads Group V8.11\bin\CivUstAT.ma" InRoads

HTH - Roy

Re: 64-bit install

zride91 — Tue, 24 Nov 2009 23:20:36 GMT

I'm stumped on using the ProgramFiles(x86) variable.

I am trying to get it to work in a key-in for one of our custom pulldown menus that starts InRoads.

The Key-in for the pull down we used is as below:

mdl l "C:\Program Files\Bentley V8i\InRoads Group V8.11\bin\CivUstAT.ma" InRoads

This worked great when everything was installed in the same location. Being this pulldown is in a dgnlib on the network, I only want one file to manage for everyone to use.

This is a great example of where I wanted to use a resolution such as Roy's.

I basically need one Key-in that points to (2) locations:

C:\Program Files\Bentley V8i\InRoads Group V8.11\bin\CivUstAT.ma

and

C:\Program Files (x86)\Bentley V8i\InRoads Group V8.11\bin\CivUstAT.ma

I have tried to use EXPAND KEYIN with a Program Files (x86) variable, but I can't get it to work with the rest of the file path. I've also tried using the _USTN_BENTLEYROOT variable to get me by the 32-bit/64-bit program structure differences, but again the key-in will not take the rest of the path.

Does anyone have any suggestions?

Thanks again!

Re: 64-bit install

zride91 — Mon, 23 Nov 2009 22:02:31 GMT

Thanks again all!

Jordan, yes on the Autodesk side of things I am in the same boat. We have not utilized Autodesk Object enablers in MicroStation yet, but I am having a heck of a time trying to get all of my Autodesk 2008 products going on the new 64-bit machines and getting all the object enablers loaded. For the 2008 releases, it seems Autodesk intentionally made some of their packages uninstallable in a 64-bit environment because it wasn't supported. I've aquired ways to work around installs for all the vertical products, but did get stuck on the MEP object enabler, it's the only one I can not get to work. I will just have to work with proxy graphics till we can deploy 2010.

Re: 64-bit install

SteveMeyer — Thu, 19 Nov 2009 19:22:44 GMT

One thing we have noticed is that any MicroStation apps we have written that communicate with Oracle will not run in the (x86) directory. It is an Oracle issue with the parenthesis in the path name. For that reason, we have gone to install MicroStation in a directory at the root and we do not have any issue with Oracle. This is on 64 bit Windows XP and 64 bit Windows 7. MicroStation XM.

Re: 64-bit install

JordanH — Thu, 19 Nov 2009 03:37:27 GMT

I would be wary of moving to 64-bit if you work with any AutoDesk Products as well. I converted and then had to change backwards to enable some object enablers to work. See link: http://communities.bentley.com/Products/MicroStation/MicroStation_V8i/f/19565/t/37695.aspx

Thanks,

Jordan

Re: 64-bit install

Roy Gallier — Thu, 19 Nov 2009 03:11:38 GMT

I created a script file with this line:

SET ProgramFiles(x86)=C:\Program Files (x86)

I apply it via group policy as a login script for all non-64 bit O.S. machine.

HTH - Roy

Re: 64-bit install

zride91 — Thu, 19 Nov 2009 01:47:27 GMT

Thank you all VERY much for the replys. I appologize for the delay, forgot to subscribe...

Roy I like your resolution the best, it would seem to keep everything to par for how Windows wants us to keep the software organized and doesn't involve me reinstalling software on any of my 32-bit machines or doing things to complicate things with my IT staff.

It seems easy enough to replace a .cfg file to include the new variables and push it out to all my users through a .bat file upon log-in, but how do you push out a system environment variable to a bunch of systems on a network?

Thank you!

Yeah, Microsoft is not at the top of my favorite people list, between this Vista adaption and the red ring on my XBox...

Re: 64-bit install

Phil Chouinard — Sun, 18 Oct 2009 17:48:26 GMT

It should not (as we test with various configurations and have not encountered any issues with that).

Re: 64-bit install

danny-cooley — Sun, 18 Oct 2009 01:24:09 GMT

Hello

Thanks for raising this issue ............. not something I would have thought of ..... and I'll soon be getting a new machine with either Vista or Windows 7 (still on XP Pro 32 bit for now)

Normally, I DON'T install MS in the root folder, I have a completely separate partition E:\ PC Apps (or something like that) where I install MS and various other apps (away from the C drive)

Would this give me problems then with Vista/Windows 7?

Regards

Danny Cooley

Freelance CAD technician

Re: 64-bit install

Roy Gallier — Sat, 17 Oct 2009 19:05:10 GMT

The way I resolved this problem (not only a USTN problem) was to create a system config variable on the 32 bit machines PROGRAMFILES(x86) = "c:\program files". I them use the variables %PROGRAMFILES(x86)% in windows paths and ${ProgramFiles(x86)} in USTN paths.

this is from the thread Workspace setting for x86 and 64 bit OS.

Re: 64-bit install

-G- — Fri, 16 Oct 2009 22:38:59 GMT

Sadly with the wonky implementation of Win64 it wants to place all 32 bit apps in "Program Files (x86)" by default. Experience has shown that the OS expects all applications in the "Program Files" folder to be 64bit.
Installing 32 bit apps into "Program Files" WILL give you problems at some point.
Since the "(x86)" decoration on the 32bit folder is against MicroSoft's own legacy rules, many applications will fail to work in one way or another if installed in this location.

Our answer is to create another root level folder, i.e. Win32Apps (to wax back to the days when upgrading from 16bit to 32bit), or simply C:\Apps\, and then install all 32bit apps (that give you an option) into that folder. There will of course be things such as shared components, etc. that will end up in "Program Files (x86)" but the core application will be in the other location.

Experience has shown that this works very well and is now our standard practice for all 32bit apps and has eliminated almost all unexplainable 32bit on 64bit issues.

If darned MicroSoft had simply decided to place 64 bit apps into "Program Files (x64)" instead of dinking with the 32bit apps folder, I suspect the transition would have been MUCH smoother.

Either way, anything you have hard coded to "Program Files" will most likely need to change to something else.

-G-

Re: 64-bit install

Phil Chouinard — Fri, 16 Oct 2009 21:02:42 GMT

Some may say this is subjective, but MicroStation is currently a 32-bit application*, and the Program Files (x86) folder is there for programs like that. The Program Files folder is intended for 64-bit applications.

* MicroStation DOES take advantage of 64-bit hardware and OS... see the MicroStation Memory Management wiki article for more information regarding that.