Working with different runtime versions.

[johnM]

I just came across a situation that I wanted to share.
If you distribute your programs there could be issues with other programs that are using different runtime versions.

I have always used the load runtime example supplied with the sample files called manualload.lsp and it works great until there is another program that is loaded with different runtime versions.

What I have done is to write a version checker that is called before the ARX load routine

(defun opdc_arx_ck (/ arxnamex proc_arch)
     (setq arxnamex        
        (strcat "opendcl"
        (if
        (and
        (setq proc_arch (getenv "PROCESSOR_ARCHITECTURE"))
        (< 1 (strlen proc_arch))
        (eq "64" (substr proc_arch (1- (strlen proc_arch))))
        )
         ".x64."
         "."
        )
        (substr (getvar "acadver") 1 2)
       ".arx"
        )        
        )
   (if (member arxnamex (arx));_see if a ARX is already loaded
        (progn
   (if (/= (dcl_GETVERSIONEX) "6.0.0.7");_check it with my version
        (progn
   (if (member arxnamex (arx)) (arxunload arxnamex 'nil));_if not my version unload it
        );_progn
        );_if
        );_progn
        );_if
   (princ)
  );_defun

If there is a better idea please post it.
Also if the sample file could be updated to cover this issue it would be extremely helpful to those of use who distribute our programs.

[BazzaCAD]

If you install the runtime with the runtime.msi & use (command "OPENDCL")
You wont have any issues & wont need to jump through all these hoops.
That's why the samples are setup this way & not with the manual loading technique.
I guess we should add some type of disclaimer and the beginning of the "manualload.lsp" file explaining that it's not the recommended technique to avid confusion.

[owenwengerd]

The current samples are very poor examples of best practice, and they really need to be fixed.  As Barry said, you should distribute and install the runtime via the runtime MSI (or include the MSM into your own application's MSI) and let Windows Installer take care of installing it on the target system, then use (command "OPENDCL") to load the runtime.  If you do this, your application will not conflict with other OpenDCL applications.  If everyone else does this, their application won't conflict with yours.

[BazzaCAD]

The current samples are very poor examples of best practice, and they really need to be fixed.

Hi Owen,
I know the samples need some help, but the loading section seams ok to me.
Each sample calls (LoadRunTime) & (LoadRunTime) calls (command "OPENDCL") & ensures demand loading is enabled.

So do you think we should remove (LoadRunTime) in each sample and replace it with (command "OPENDCL")?

[Kerry]

Most of the hoop jumping code was written before demand loading was available.

Personally I now don't rely on any external lisp files.

I simply put (command "OpenDcl") as the first line of the file so it gets evaluated when the file loads.

and use something like this to load the project
  (or (dcl_project_load "KDUB_BlaBla" )
      (prompt "\n Unable to load KDUB_BlaBla Dialog")
      (exit)
  )

... but that's just me

[BazzaCAD]

That sounds good to me, my only concern is what if they have demand loading disabled...
Then they get "unknown command OPENDCL"

[johnM]

Please correct me if I am wrong, but I think I’m lost

You can query the system variable “Demandload” to see if it is on or off

Runtime MSI will install the runtime files located at c:\program files\common files\openDCL\.
Runtime MSM will install the runtime files located at c:\program files\common files\<my software>\.

Now if demand load is enabled and from my program I call (command “opendcl”)
My program will be linked to those runtime arx files installed from the MSM  and even if someone else has a programmed that loaded a ARX file into AutoCAD that arx file will not be linked.

Also if the above is correct I assume the demand load knows which runtime arx to load
(.Arx.16-arx.17-arx.18 ect….) for the correct acad version

[owenwengerd]

That sounds good to me, my only concern is what if they have demand loading disabled...
Then they get "unknown command OPENDCL"

My opinion is that if DEMANDLOAD is set to zero, then software should assume it was set that way purposely to prevent stuff from loading (i.e. while testing someting, or debugging a problem).  If a developer wants to do that sort of checking in their own code, fine, but such code shouldn't be in the samples.

[owenwengerd]

Runtime MSM will install the runtime files located at c:\program files\common files\<my software>\.

If it does, it's a bug.  The MSM should install the runtime files in the Common Files folder same as the MSI.  You're correct about filenames; the installer writes everything into the registry to set up the demand loading for every supported AutoCAD and Bricscad installation on the system so that application code does not need to worry about it.

[BazzaCAD]

That sounds good to me, my only concern is what if they have demand loading disabled...
Then they get "unknown command OPENDCL"

My opinion is that if DEMANDLOAD is set to zero, then software should assume it was set that way purposely to prevent stuff from loading (i.e. while testing someting, or debugging a problem).  If a developer wants to do that sort of checking in their own code, fine, but such code shouldn't be in the samples.

OK then I try to start updating the samples when I get some time.

[Kerry]

That sounds good to me, my only concern is what if they have demand loading disabled...
Then they get "unknown command OPENDCL"

Perhaps that could be covered by a section in the help " ERROR Messages , and what they mean"

Barry I can spare a couple of hours in the morning so I'll start the sample updates if you like.

[BazzaCAD]

ok sounds good

[johnM]

I believe there should be a section on runtime conflicts and how to avoid them.
There should be a standard set and a good sample on how to implement the load.
A lot of the users like myself learn by example and if we are started off in the right direction it is better for all. Of course there always be exceptions.
I would be happy to contribute to the writing of this topic but I don’t know what the hell I’m talking about at this stage, but I will figure it out soon.
For now could someone explain or show an examples of:
How does the MSM work?

I use INNO setup: what files should I include MSI , MSM
Are there any parameter switches?

I’m just trying to wrap my brain around this so please bear with me.

[owenwengerd]

There is an Inno Setup tutorial here:
http://opendcl.com/wordpress/?page_id=10

[johnM]

Thanks for the link
I read through it and it covers the MSI install but nothing about MSM

The MSI install will install the runtime files at C:\Program Files\Common Files\OpenDCL

Unless I missed something this doesn’t solve any problems. What a user installs my program that uses runtime 4.1.1.x and then a week later installs a different program containing runtime 6.0.0.8. that install would overwrite the files in C:\Program Files\Common Files\OpenDCL and now my program will have issues.
Is this correct?