Jump to content











Photo
- - - - -

Possible values for the %Variables%


  • Please log in to reply
10 replies to this topic

#1 Voltaire

Voltaire

    Member

  • Members
  • 36 posts
  • Location:Lawrenceville,GA
  • Interests:Programming in assembler,Computers,Computers,Computers.
    SciFi,Single Malt Scotch
  •  
    United States

Posted 19 April 2013 - 03:56 AM

I feel so noobish. :cheerleader:   I can't seem to find anything that lists the possible valid values for all the variables used in scripts. (Race is on to point to what I can't find by search)

So, for example, if I want to tweak a script based on the SOURCE OS, I would prsumably use %OS% but what values can it have?

Win7 shows in mine because that is what I build from/for.  Would Win5 <XP>,Win6 <or vista>,Win8 be valid? And in this example would there be differentation for Service Pack levels?

Is %SysType% the host arch?  Assuming source indicated by %SourceArch%,

 

 

 

 

 

 

P.S.  Would be ecstatic to help with documentation.



#2 Centaur

Centaur

    Newbie

  • Members
  • 23 posts
  •  
    United States

Posted 19 April 2013 - 07:06 AM

the %OS% var in XP (sp3) shows

 

OS=Windows_NT



#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15540 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 April 2013 - 09:01 AM

Wait a minute. :ph34r:

You must somehow distinguish between Environment variables ("belonging" to  the NT system) and Winbuilder variables.

%OS% is an environment variable.

See:

http://www.techrepub...riables/5986211

 

The %OS% environment variable is pretty much useless to determine actual OS (traditionally), particularly since the (demented) guys at MS started differentiating the OS by more complex means also the Winbuilder variable may be not accurate enough.

 

The Winbuilder variable is %HostOS%:

http://www.paraglide..._variables.html

http://code.google.c...scriptvariables

 

 

 

 

%HostOS% - string representing the OS of the host running WinBuilder
if majorVersion <= 4 then HostOS = NT
if majorVersion = 5 and minorVersion = 0 then HostOS = W2000
if majorVersion = 5 and minorVersion = 1 then HostOS = XP
if majorVersion = 5 and minorVersion = 2 then HostOS = W2003
if majorVersion = 6 and minorVersion = 0 then HostOS = Vista
if majorVersion = 6 and minorVersion = 1 then HostOS = Win7

but you need an additional check to distinguish between Vista :ph34r: and Server 2008, 7 and Server 2008 R2 and  8 and Server 2012 (cannot say if currently 8 aka NT 6.2 is detected).

 

From the mouth of the (stupid) wolf:

http://msdn.microsof...2(v=vs.85).aspx

http://msdn.microsof...3(v=vs.85).aspx

http://msdn.microsof...4(v=vs.85).aspx

 

:cheers:

Wonko



#4 Voltaire

Voltaire

    Member

  • Members
  • 36 posts
  • Location:Lawrenceville,GA
  • Interests:Programming in assembler,Computers,Computers,Computers.
    SciFi,Single Malt Scotch
  •  
    United States

Posted 19 April 2013 - 02:42 PM

...the variables used in scripts....

Thought that made it clear, guess not. Let me try again.

If the %var% is used in the script, I am talking GLOBAL, I ASSumed it was set by a script and not copied from the windows environment.

 

My question regarding the particular variable was as to the SOURCE version, which would not be in the Windows environment (except when they are the same).

 

SOMEWHERE, it seems to me, the project must know what the source (and thus the target) os version is. Or maybe NOT?

Given that a project has a fixed target, eg Win7PESE, vs LiveXP,etc, there must be SOMETHING that would be a reliable indicator that an App script could use to know the intended target is.  If SP level etc has not been ascertained {all you clever guys haven't done this already? :mega_shok:  } then that would be left as a study in methodology.

 

All this being said, is there a list of valid values for the WinBuilder variables?



#5 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 19 April 2013 - 03:20 PM

Besides many other useful information, WinBuilder help explains variables: http://code.google.c...scriptvariables.

 

All variables not explained in the help, are not "WinBuilder Variables" and declared / maintained under the responsibility of the particular project.

 

Peter



#6 Voltaire

Voltaire

    Member

  • Members
  • 36 posts
  • Location:Lawrenceville,GA
  • Interests:Programming in assembler,Computers,Computers,Computers.
    SciFi,Single Malt Scotch
  •  
    United States

Posted 19 April 2013 - 03:33 PM

... WinBuilder help...

Which is useless regarding what I want to know, and why I came asking... So it would seem I need to ASK the right question. :white_flag:

What are the PROJECT variables - and are they even close to being constant ACROSS projects, and thus (drum roll) what would be the valid range of values for the PROJECT variables?  I am begining to suspect I am in a version of an Abbot & Costello routine.



#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15540 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 April 2013 - 03:48 PM

Which is useless regarding what I want to know, and why I came asking... So it would seem I need to ASK the right question.  :white_flag:

 

 

Yes, maybe you asked the wrong question or asked it in the wrong way. :dubbio:

 

I replied to the "example" question you made, about the %OS% variable, nothing more, nothing less.

 

Sorry if it seems to you that you were tricked in an Abbot/Costello routine. 

 

:cheers:

Wonko



#8 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 19 April 2013 - 03:53 PM

Maybe you have an understanding issue with the lifetime of variables. That is also described in the help.

But maybe shorter here:

 

Variables declared in script.project are valid for the whole build.

I think that is what you mean with "project variables".

Every project developer can define project variables like he wants. Some developers try to use known and often used conventions, some invent their own proprietary style which of course is not or only rarelly compatible with other projects.

Logically there can be no definition of "Valid Range".

 

Variables declared in a script are valid only during processing of the script.

Exception: When you declare a variable wit "Set, .... ,GLOBAL" this variable is valid for the remainder of the build.

 

Caution: When a script1 calls a different script2 using "Run", you are logically still inside script1.

Script1 variables are known, script2 variables are unknown.

When a script1 calls a different script2 using "Exec", you are logically inside script2.

Script2 variables are known, script1 variables are unknown.

WinBuilder offers the function "AddVariables" and "AddInterface" to get knowledge about such "off topic" variables.

 

Peter



#9 Voltaire

Voltaire

    Member

  • Members
  • 36 posts
  • Location:Lawrenceville,GA
  • Interests:Programming in assembler,Computers,Computers,Computers.
    SciFi,Single Malt Scotch
  •  
    United States

Posted 19 April 2013 - 04:33 PM

Thanks pscEx, answers my question.

Drat!   No easy answers then, unless the maker of Winbuilder itself were to change by adding more functionality (ahem).

So it looks like I have some work to do, figuring out what I need within the app script itself. wah wah wah

 

 

So whats in a variable?

Whats? He's in a different variable.

Which variable?

Yes!

No, which variable is what in?

What in?  He's not here. 

No, whats the name of the variable?

Exactly! etc etc etc :chair:



#10 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 19 April 2013 - 05:00 PM

..., unless the maker of Winbuilder itself were to change by adding more functionality (ahem).


You know that since several years I'm the developer of WinBuilder.exe ? :cheers:

 

Your question and a look into your profile (Interests: Programming in assembler) causes an opinion in me. Maybe you did not work a lot in higher languages before.

Please, do not understand me wrong, I do not want to declare you as fool.

Maybe my low English knowledge hinders me to understand your real intention.

 

A variable is "something" given to knowledge to the running application, identified by a name. "Something" can be eyerything, starting from a simple integer, character or string, upto complexe objects like a multimedia player etc. For the compiler "Variable" is identified by the name.

 

WinBuilder only works with variables of the type "string". The scripts interpret these strings as integers, boolean, character, when necessary.

 

In WinBuilder the identifying name of the variable is %the_name_I_as_developer_gave_to_this_variable%

WinBuilder uses the percent % to trigger handling a variable.

 

When WinBulder sees a %the_name_I_as_developer_gave_to_this_variable%, it replaces this by the contents of the variable ("Something").

 

Simplest low level:

Set,%myvariable%,mycontents

...

When building the project, WinBuilder replaces every following %myvariable% by "mycontents".

 

Peter

 

BTW: From 1981 ... 199? I programmed mainly in DEC PDP11 assembler. And then Billy the Door appeared ...



#11 Voltaire

Voltaire

    Member

  • Members
  • 36 posts
  • Location:Lawrenceville,GA
  • Interests:Programming in assembler,Computers,Computers,Computers.
    SciFi,Single Malt Scotch
  •  
    United States

Posted 21 April 2013 - 06:42 PM

pscEx,

Yes I am aware you are the devloper - thus the AHEM at the end.  Perhaps I sould have said nudge,nudge  or wink wink.

As for my knowledge in higher languages....I program in assembler because I LIKE IT, and I do in Windows, and BTW you CAN program at as "high" a level as you like/need in assembler.  As for this discussion, since Winbuilder is a system - IMO it should provide basic information, or API's (whatever) that could be used by the scripts that run within said system.  I am not trying to put more work on you, or detract from the fine work that has been done.  Just making inquires as to what was available.

 

My boring history with all things computer;

Building electronic projects when I was 9, built several analogue computers by age 10 or 11 (electronic slide rules of sorts)

Built and programmed a Cosmac Elf in Jr. College    :clap: Addicted to ML programming. :clap:

Interfaced to and programmed an an old PDP11 in college, along with learning programming in Fortran and Cobol on an IBM mainframe.

Punchcards,paper tape, Teletype terminals (shudder) and other (now) outdated crap.

Learned Basic on a Interact Model 1 (8080 based) but wrote my own ML assembler for it using the ROM basic then got an Atari 800.

Learned BASIC, and C (Deep Blue C compiler) but went back to ML (6502) on it as well.

Again BASIC on an IBM XT, tried M$ macro assembler -HATED IT. Learned Watcom C (loved it), eventualy C++ (also hated it).

Windows came along,played with visual basic and the first ver of M$ Visual C (I think they called it).

Long gap with ocassional bouts writing SQL, batch files, a couple of other scripting languages, but nothing constant.  Took up ML programming on/off several more times over the years.  But mostly not, never have time  -and I forget too much in each gap.

So now, I am your problem (not - just kidding)






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users