Visual Basic

The Loggers

Either the C application or the Visual Basic application listed at the end of this section (and on the CD) can be used to replace the real C2.EXE file. To replace it, follow these steps for the C version:

  1. Make backup copies of C2.EXE and LINK.EXE.
  2. Rename C2.EXE to C3.EXE.
  3. If you want to rebuild the C application, make sure that the first real line of code in the OUTARGS.C source file reads as follows:
    strcpy(&carArgs[0], ".\\C3 ");

    The binary version on the CD already includes this line of code.

  4. Copy the EXE (OUTARGS.EXE) to C2.EXE.
    copy outargs.exe c2.exe
  5. Your original C2.EXE is now C3.EXE, so no damage is done.

    Use Visual Basic 6 as you normally would.

The steps for using the Visual Basic version are a little different. To replace C2.EXE with the Visual Basic application, follow these steps:

  1. Make backup copies of C2.EXE and LINK.EXE.
  2. Compile the code to OUTARGS.EXE (make sure your project contains just the OUTARGS.BAS standard module-no forms or anything else).
  3. Rename C2.EXE to C3.EXE. Rename LINK.EXE to L1NK.EXE. (Note that the "i" has been changed to a "1".)
  4. Copy the EXE (OUTARGS.EXE) to C2.EXE and LINK.EXE. Your original C2.EXE is now C3.EXE and your LINK.EXE is now L1NK.EXE, so no damage is done.
  5. Run REGEDIT.EXE, and under HKEY_CURRENT_USER\Software\VB and VBA Program Settings insert two new keys (subkeys and values as shown here):
    HKEY_CURRENT_USER\Software\VB and VBA Program Settings\
                      \RealAppName    ".\C3"
                      \RealAppName    ".\L1NK"
  6. Use Visual Basic 6 as normal.

The purpose of the Visual Basic version of OUTARGS.EXE is to have the same binary self-configure from a Registry setting. This means that you only need one OUTARGS.EXE (renamed appropriately) to "spy" on any application.

The output of the Visual Basic application is a little less fully featured than that produced by the C application. After you've carried out either of these steps, the following will happen: When Visual Basic 6 runs (to compile to native code), it will run C2.EXE. C2.EXE, which is really our OUTARGS.EXE program, will log the call made to it to the file C2.OUT. (Our application logs to a file based upon its own name, <EXEname>.OUT; because our application is renamed C2.EXE, the log file will be C2.OUT.) Information logged includes the parameters that have been passed to it. C2.EXE will then shell C3.EXE (the "real" C2), passing to it, by default, all the same parameters that it was passed. The net effect is that you have logged how C2 was invoked.

The Visual Basic OUTARGS program will also be used to log the linker, if you followed the steps above. Listing 7-1 is a typical C2.OUT log (C version).

Listing 7-1 Typical C2.OUT log file

  ********** Run @ Wed Jan 1 00:00:00 1998
  * EXE file...
  * Command Line Arguments...
  1       -il
  2       C:\WINDOWS\TEMP\VB476314
  3       -f
  4       Form1
  5       -W
  6       3
  7       -Gy
  8       -G5
  9       -Gs4096
  10      -dos
  11      -Zl
  12      -FoC:\TEMP\Form14.OBJ
  13      -QIfdiv
  14      -ML
  15      -basic
  * 'Real' program and arguments...
          .\C3 -il C:\WINDOWS\TEMP\VB476314 -f Form1 -W 3 -Gy -G5
          -Gs4096 -dos -Zl -FoC:\TEMP\Form14.OBJ -QIfdiv -ML -basic
  ********** Run End

The Visual Basic team seems to have added a space between the -W and the 3, possibly causing C2 to interpret this as two separate switches. Since C2 doesn't error or complain, I'm assuming that it knows to treat the switch as W3 (warning level set to 3).

By further altering the code (again, the C version is demonstrated here), you can change, add, or remove compiler switches. For example, you can add the following code to the argument processing loop to replace, say, -G5 with, say, -GB, the "blend" switch mentioned earlier in our discussion of -G5.

  if (0 == strcmp(argv[nLoop], "-G5"))
      (void)strcat(&carArgs[0], "-GB ");

The C version OUTARGS.EXE doesn't like long pathnames that include spaces. Each "gap" causes the next part of the pathname to be passed to C3 as a separate command-line argument. To fix this, either alter the C code to quote delimit each pathname or copy your test Visual Basic project to, say, C:\TEMP before attempting to use it; that is, remove any long pathname. (Leave the renamed OUTARGS C2.EXE in the same folder as the real, now renamed, C3.EXE.) Note that the Visual Basic OUTARGS.EXE doesn't have the same problem.

To restore the "real" program, simply copy over C2.EXE with C3.EXE:

  copy c3.exe c2.exe