GWScript

GWScript - written gws or GW-Script by its vendor - is a proprietary, C-like scripting language embedded in GW-TEL INFRA-XS, an end-to-end monitoring suite built by the German firm Geyer & Weinig EDV-Unternehmensberatung GmbH. It exists for one purpose: to describe, step by step, what a synthetic user does to an application, so that the time and outcome of every step can be measured continuously and reported against a service level agreement.

It is a good example of a category of language that is numerically enormous and almost entirely undocumented in public: the vendor scripting language. Thousands of commercial products embed one. They have real syntax, real type systems and real standard libraries, they are written by real programmers for a living, and they leave almost no public trace, because the only people who write them are customers working inside a licensed product. GWScript appears in language catalogues at all only because someone at the company posted a program that sings about beer.

What the Public Record Actually Contains

Honesty about sourcing matters more than usual here, because there is so little to source from. Nearly everything specific that can be said about GWScript syntax comes from a single artifact: a 99 Bottles of Beer implementation published on 20 April 2005, whose comment header names Timo Boll of Geyer und Weinig GmbH as its author and points at the company’s site. That header carries the vendor’s own one-sentence definition of the language, describing GWS as a C-like scripting language used in load testing, quality assurance and service level management.

The other primary source is the vendor’s own writing about the host product, which confirms that gws is an integral component of INFRA-XS and describes what has been built with it. No public grammar, reference manual, interpreter or downloadable toolchain has been located. Nothing on this page should be read as a claim about GWScript’s full feature set; it is a description of a small, verifiable window onto a larger proprietary language.

The 2002 first-appearance date carried by language catalogues, and reproduced in this page’s front matter for consistency with them, could not be corroborated against any primary source. What is verifiable is that GWScript existed and was in use by April 2005, and that its host product dates to the mid-1990s.

The One Public Program

The surviving sample is worth reading closely, because a dozen lines of a language written for a purpose tell you more about that purpose than a marketing page does.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// GWScript (GWS) is a C-like scripting language used in (load) testing,
// quality assurance and service level management.
// This piece of code uses Windows Notepad as an "output device".

main () {
  int l_bottle_cnt;

  if (execcmd( sysgetenv( "windir" ) + "\\notepad.exe", 512 + 5 ) > 0) {
    for (l_bottle_cnt = 99; l_bottle_cnt > 0; l_bottle_cnt --) {
      kputs( strform( "%d bottle(s) of beer on the wall,\r", l_bottle_cnt ));
      kputs( strform( "%d bottle(s) of beer.\r", l_bottle_cnt ));
      kputs( "Take one down, pass it around,\r" );
      kputs( strform( "%d bottle(s) of beer on the wall.\r\r", l_bottle_cnt - 1 ));
    }
  }
}

Almost every line is evidence of something.

The surface is C. A main() entry point with no return type, a declaration block at the top of the function, int as a primitive, C-style // comments, a three-clause for loop, postfix --, and printf conventions preserved intact in strform down to %d. A C programmer can read this without instruction, which is the entire point of a language aimed at test engineers rather than at compiler enthusiasts.

But + concatenates strings. sysgetenv("windir") + "\\notepad.exe" builds a path. C-like syntax, higher-level string semantics - the standard bargain of a scripting language that borrows C’s punctuation without inheriting its memory model.

The naming convention is disciplined. l_bottle_cnt carries an l_ prefix for a local. That is a Hungarian-descended house style typical of large, long-lived script libraries maintained by many hands, and it suggests the language is used at a scale where such conventions pay for themselves.

The library reveals the domain. Three of the four called functions are not general-purpose:

kputs is the tell. This is not a language for computing values; it is a language for operating an application. The whole sample is a synthetic transaction in miniature: locate the program, launch it, verify it launched, type into it. Replace Notepad with an SAP GUI or a banking front end, add timing and assertion around each step, and it is a production INFRA-XS measurement.

The failure handling is characteristic. if (execcmd(...) > 0) guards the entire body. A monitoring script that keeps typing into a window that never opened produces not a failed measurement but a corrupt one, so checking the launch is not defensive politeness - it is the difference between a usable data point and a lie in a service level report.

Design Philosophy

Three commitments show through even in so small a sample.

Familiarity over elegance. The audience is QA and operations engineers, not language enthusiasts. Choosing C syntax in the early 2000s meant that anyone who had written C, C++, Java, JavaScript or PHP could start immediately, and it meant the vendor never had to argue for its syntax.

Automation of the human, not the interface. Contemporary alternatives frequently measured protocols: fire an HTTP request, time the response. Driving the actual GUI through keystrokes measures what the user measures, including the client-side rendering, the terminal-server round trip and the fat-client delay that a protocol-level probe never sees. That is a harder engineering problem and a more honest number, and it explains why the language needs process control and input injection in its core library rather than in an add-on.

A substrate, not a finished product. The 2018 DSL work is the clearest statement of intent. Rather than adding a feature to INFRA-XS for adaptive API monitoring, the vendor’s engineers wrote a domain-specific language in gws that reads API metadata and rewrites its own test cases when the interface changes. A language used that way is treated by its own maintainers as a general programming substrate, not as a macro recorder.

Where GWScript Fits

The market GWScript was built for was crowded and is largely forgotten. Mercury Interactive’s LoadRunner scripted virtual users in a C dialect; WinRunner used TSL; Segue SilkTest used 4Test; Compuware and others fielded their own. Each vendor shipped a bespoke language because each needed primitives - virtual user identity, transaction boundaries, GUI object addressing, correlation of dynamic session values - that no general-purpose language of the era supplied.

Two things distinguish GWScript within that group. It came from a small independent German vendor rather than one of the large American test-tool companies, so it was never acquired, absorbed or retired the way most of its contemporaries were. And its centre of gravity was production monitoring and service level management rather than pre-release load testing. A load test script runs for an afternoon before a release; a monitoring script runs every few minutes for a decade. That difference shapes a language’s priorities toward stability, defensive checks and long-term maintainability rather than expressiveness.

Platforms

Only Windows-side operation is documented in the sources reviewed here. The public sample reads the windir environment variable and launches notepad.exe, and the vendor’s own multisession container announcement describes running parallel GUI applications and Citrix terminal sessions on a Windows measurement agent. The vendor markets INFRA-XS more broadly, including monitoring of web, mobile and mainframe applications and deployment in data centres or leading cloud environments, but this page makes no claim about which platforms the GWScript runtime itself executes on beyond the Windows agent evidence above.

Status: Dormant in Public, Alive in Private

Language catalogues classify GWScript as dormant, and by the measures those catalogues apply - public releases, open documentation, community, package ecosystem, visible code - that is correct. There has been essentially nothing since the 2005 sample.

The vendor record says something different. The 2018 article describes active DSL development in gws; INFRA-XS reportedly reached version 10 in September 2024, with Git integration for managing monitoring agents; and the vendor still sells and develops the suite. The language is therefore best described as commercially live and publicly invisible.

That gap is itself the interesting fact. A language can plausibly be written every working day by paid engineers inside licensed enterprise deployments, and still be indistinguishable from a dead language to anyone outside that customer base - because there is no repository to count stars on, no questions to ask on a forum, and no way in.

Why It Matters

GWScript will not appear in a history of programming language design. It contributed no new idea; it deliberately borrowed a syntax that was already twenty years old when it adopted it.

Its interest is as a specimen. It documents what the enormous, unlit portion of the programming language population actually looks like: a competent C-like scripting layer, a standard library shaped entirely by one domain, a naming convention that implies a large maintained codebase, and a total public footprint of about fifteen lines of code, contributed to a joke website, that happen to be the only reason anyone outside its customers knows the language ever existed.

It is also a reminder about how catalogue metadata is made. Because a single anonymous submission in 2005 caught the language, GWScript is enumerated, dated, given a paradigm and a category, and reproduced across derived lists - each of which restates a first-appearance year that, so far as this page could determine, nobody ever published a source for.