I have searched all over this site and over at Sprezz, and cannot find the answer to what I think is a simple question.

When you deploy a run-time ARev 3.x system, exactly what commands are disabled? I can think of some obvious ones like DICT, COMPILEBASIC, PAINT, MAKEMENU, and MAKEPOPUP, but I'm sure there are a number of others.

I did run across the SEC(13) reference and identified a number of windows in SYSWINDOWS that implement this as their Pre-Init hook, so that makes sense.

Basically, what I need to do is create a user profile in HR-1 (with a dev-ready engine) that mimics being on a runtime engine.

Any ideas, or do I just need to troll through VOC and SYSOBJ to see what I find?

TIA,

[email protected]

Greyhound Lines, Inc.

Also, this is the short-term fix. I am investigating moving to a runtime engine, but that has to wait on several other projects to complete first.

[email protected]

Greyhound Lines, Inc.

I can't find a copy of my comprehensive document, but this might work for you.

Since the runtime messages are 140 and 140.2, and these are usually literal strings, like call msg( 140, 'A', , ), then a search for 140 in the object code might do the trick.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Okay, so here's a follow-on question.

I found a snippet for an auto-save routine in a back issue of SENL. One of the aspects was to verify that you are on a dev-ready copy so that runtime users didn't have weird files all over their file system.

The trick to verifying that it was a dev-ready system was:

BitAnd(RunTime(), 2048)

If this evaluates to true (which it does in my system) then you are on a development engine. I poked around and it appears that the RunTime() call is an internal function. Is there any way to override this function so that my dev-engine *thinks* it's a runtime?

My guess is that the answer is no, and that this is the principle difference between a dev-ready and a runtime engine.

[email protected]

Greyhound Lines, Inc.

I'm not 100% sure exactly what was used for the runtime. There were a series of bits in a byte which were used to allow certain options. So if one bit was set, then you could paint, another allowed compilation, another allowed file creation and so forth. The old Runtime+ that shipped with AREV 3 or 3.1 had a different set of bits set, which was how it allowed for additional features in the runtime.

Just checking for 2048 might be a good generic method, but it's probably not guaranteed to work.

Probably the best think to do is have a test program and run it through RTP5 and check the results. If you can complile it without error, then it's probably a development copy, if not it would be a runtime.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Actually, I'm not too worried about determining if a system is a run-time or not. I had just noticed that little snippet that appeared to make the determination and was wondering if there was some way to override the Runtime() function so that a dev-ready system thought it was a runtime system.

That would greatly simplify my quick-and-dirty lockdown of our Production environment.

Guess it's back to trolling through VOC and SYSOBJ to identify development commands and restricting access to them.

BRAIN FLASH!!!

I vaguely remember something about security levels within ARev, and that you could set default run levels (is that the right phrase) for windows. If a user did not have the right run-level a window would not open.

To my knowledge, Ceridian's HR-1 does not use these run levels but its own custom security. However, I'm willing to bet that these run levels are still implemented, since they are core functionality. Methinks I could set a default run level on the development command windows in SYSWINDOWS and that would restrict access.

(Y)es, (N)o, (M)aybe, (D)ie Horribly?

[email protected]

Greyhound Lines, Inc.

My guess is probably, but then I'm not really up on my HR-1.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

View this thread on the forum...