third_party_content:community:commentary:forums_nonworks:f27ff30eac3d9bc085256fc4007c36a1

Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 14 MAR 2005 06:36:44PM Matt Sorrell wrote:

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,

msorrel@greyhound.com

Greyhound Lines, Inc.


At 14 MAR 2005 06:38PM Matt Sorrell wrote:

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.

msorrel@greyhound.com

Greyhound Lines, Inc.


At 15 MAR 2005 06:21AM support@sprezzatura.com wrote:

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.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft


At 15 MAR 2005 10:37AM Matt Sorrell wrote:

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.

msorrel@greyhound.com

Greyhound Lines, Inc.


At 15 MAR 2005 10:51AM support@sprezzatura.com wrote:

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.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft


At 15 MAR 2005 11:21AM Matt Sorrell wrote:

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?

msorrel@greyhound.com

Greyhound Lines, Inc.


At 15 MAR 2005 11:32AM support@sprezzatura.com wrote:

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

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/f27ff30eac3d9bc085256fc4007c36a1.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1