Database Search
If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.
TechHome
Console Wrapper
Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.
Console Wrapper Extender
Keywords: ConWrap Console Wrapper Wrap
The Console Wrapper Extender fully supports redirected STDIN, STDOUT, and STDERR with piping and all that.
[packtemp-1[1].2.1.zip]
[conwrap-10005.zip]
[source-packtemp-1[1].2.1.zip]
PackTemp Readme
Developed by Artomegus
PackTemp 1.2
=============================================================================
-- Description and syntax
Packs a compiled WinBatch script and optional additional files.
PACKTEMP [/C] [/O destination] [/Y] source [file [...]]
/C Uses the console wrapper stub in the output file.
/O destination Specifies the path and filename for the output file.
/Y Suppresses prompting to confirm overwrite of output file.
source Specifies the source executable.
file Optional file(s) to be included in the packed executable.
If no destination is specified, the output file will go in a subdirectory
named packtemp in the same directory as the source executable, and the output
file will have the same name as the source executable.
-- Features
PackTemp will pack one or more files into a single executable. The
resulting executable will unpack the files to a temporary directory, and
then run the source executable (the first file in the list). After the
source executable terminates, the temporary directory will be deleted.
The temporary folder will be placed in the current user's temporary
directory (specified by the environment variables TMP or TEMP). The name
of the folder will be the string "es-" followed by a unique hexadecimal
number.
When creating the output file, PackTemp will copy the icon and version
information from the source executable to the output file, so that the
appearance matches that of the source executable.
PackTemp is a console-based application that will log its output to the
console (which can be redirected to a file of course). PackTemp will
return an exit code of 0 for success or 1 for failure.
-- The source files
For each file listed after the source executable, PackTemp will use a
special search algorithm to reduce the need for having multiple copies
of extender DLLs in different folders.
If the file path is unqualified (i.e. it doesn't start with a drive letter
or backslash), PackTemp will search for it first in the directory of the
source executable. If the file is not found there, PackTemp will check if
the WinBatch redistributables folder is installed on the local system,
and will search there next. Lastly, if the file is not found there,
PackTemp will check the current working directory.
-- The stub program
The core of the output file is a stub program that takes care of extracting
the files, waiting for the source executable to finish, and cleaning up
afterwards. There are two different stub programs: the standard stub
and the console wrapper stub.
There are common features between both stub programs. Both stubs will set
the priority of the source executable based on the priority used to start
itself, and both stubs pass along the command-line parameters in the same
way (more on this later). Finally, both stubs will set their own exit code
to match the exit code of the source executable.
Additionally, when starting the source executable, both stub programs
override the current working directory by setting it to the temporary
folder where the source executable was unpacked. This is done to prevent
compiled WinBatch scripts from looking for DLLs in the current working
directory of the stub program, which could lead to DLL conflicts and could
prevent proper extraction of files in WinBatch scripts compiled with the
"Large EXE" option.
If the source executable needs to know the original working directory, it can
examine the initial command line parameter passed by the stub program. See
the section below on command line parameters for more information.
-- The standard stub
The standard stub will pass along the same startup information (window
position, etc.) that was used to start itself. It doesn't create any windows
of its own; it simply unpacks the files to a temporary folder, starts the
source executable, waits for it to terminate, and then deletes the temporary
folder.
If the standard stub encounters an error unpacking the files, or any other
fatal error prior to starting the source executable, it will create a file
in the user's temp directory (TMP or TEMP environment variable) named
packtemp-crashlog.txt, and the stub will return an exit code of 1.
-- The console wrapper stub
The console wrapper stub is intended to be used in conjunction with the
console wrapper extender, which allows the compiled WinBatch script to access
STDIN, STDOUT, STDERR, and console I/O like a standard console application.
See the conwrap-readme file for more information on using the console wrapper
extender.
Unlike the standard stub, the console wrapper stub does not pass along the
its startup information, because the console wrapper itself is the front end
for the application, and the compiled WinBatch script runs in the background
sending and receiving data to and from the console wrapper. In fact, when
using the console wrapper, it is best that the compiled WinBatch script runs
hidden to prevent confusion.
By default, PackTemp will use the standard stub, unless the /C switch is used.
If you use the console wrapper stub, be sure to include the console wrapper
extender file (WCONW34I.DLL) in the compiled WinBatch script, or include
it in the packed executable.
If the console wrapper stub encounters an error unpacking the files, or any
other fatal error prior to starting the source executable, it will log a
diagnostic message to STDERR and will return an exit code of 1.
-- Command line parameters
One of the problems with being extracted to a temporary folder is that
the WinBatch script would not normally be aware of the path of the original
stub program that was executed. Also, both stub programs set the source
executable's working directory to the temporary folder containing it. To
solve these problems, both stub programs modify the list of parameters passed
to the source executable.
One additional parameter is inserted at the beginning of the list. The
parameter is actually an item list delimited by the vertical bar (|) symbol.
The first item in the list is the string "<:packtemp:>". This can be used by
the script to determine whether or not it was executed by a stub program.
The second item in the list is the original path and filename of the stub
program that was executed. The WinBatch script can use this information
in the same that it would use IntControl 1004. The third item in the list
is the original current working directory at the time the stub program
was executed. The WinBatch script can use this information with the
DirChange command to set the current directory.
Here is a code sample indicating how one might check if the script was
run by stub program:
; check if we were run from by a packtemp stub
bPackTemp = @FALSE
if param0
if "<:packtemp:>" == ItemExtract(1, param1, "|")
sStubFile = ItemExtract(2, param1, "|")
sStubDirCurrent = ItemExtract(3, param1, "|")
bPackTemp = FileExist(sStubFile) && DirExist(sStubDirCurrent)
endif
endif
The above snippet of code does some minor validation of the items passed to
it to verify that the stub file and working directory exist. If the
information checks out, the bPackTemp variable will be @TRUE. After the
script has added all its extenders, it can then use the following code
to set the current directory back to the original working directory:
; if a stub started us, change to original working directory
if bPackTemp then DirChange(sStubDirCurrent)
-- Cleaning up
It is important that the source WinBatch executable does not create any
subdirectories in the temporary folder to which it was extracted. The
stub program has a simple cleanup algorithm and will not recursively
delete directories within the temporary folder. Also, it is important
that no files in the folder remain locked by other programs after the
WinBatch executable terminates. Otherwise, the stub program will not
be able to remove the files and delete the temporary folder.
-- Operating system compatibility
PackTemp (and its resulting output files) will not run on Windows 95,
Windows 98, or Windows ME. It will only run on a Windows NT-based
operating system, which includes Windows XP, Windows 2000, and Server 2003.
-- Examples
The following command would create a packed executable named SOURCE.EXE in
the directory "C:\packtemp":
PACKTEMP C:\SOURCE.EXE
The following would create a packed executable named OUTPUT.EXE in the
current working directory, and would look for SOURCE.EXE in the current
working directory:
PACKTEMP /O OUTPUT.EXE SOURCE.EXE
The following would create a subdirectory named "packtemp" in the current
working directory. Within the subdirectory, it would create a packed
executable named SOURCE.EXE using the console wrapper stub, and
automatically overwriting any existing file. The files WBDDD34I.DLL
and WCONW34I.DLL would be included in the packed executable:
PACKTEMP /C /Y SOURCE.EXE WBDDD34I.DLL WCONW34I.DLL
-- Notes
PackTemp was packed using itself (a non-packed version of course) and makes
use of the console wrapper stub and the console wrapper extender.
=============================================================================
Change log
=============================================================================
Version 1.0, 24-Aug-2005
First release
Version 1.1, 26-Aug-2005
The stubs now modify the command line parameters differently. Instead
of inserting multiple parameters at the beginning, the stub programs now
insert a single parameter, which is an item list delimited by the
vertical bar (|) symbol.
The stubs set the current directory of the source executable to the
temporary folder where it was extracted. This prevents the compiled
script from searching for DLLs in the current directory of the stub
program. The current directory of the stub program is now in the list
of data contained in the first parameter passed to the source executable.
Additional error checking was added to packtemp.wbt to prevent duplicate
file names in the file manifest.
The conwrap-readme.txt file was modified to reflect changes in the way
the packtemp console wrapper stub operates. No changes were made to
basic functionality of conwrap.exe or wconw34i.dll. Conwrap.exe was
re-compiled to account for minor changes in the error-handling code
code shared between it and the console wrapper stub.
The source code project files were cleaned up to change them to use the
Release configuration as the default, and to fix an issue where a
header file (strsafe.h) was included in several projects via a relative
path, and would probably prevent compilation on other systems.
Version 1.2, 31-Oct-2006
Fixed bug in stub detection code (and example in this document).
Updated to include Conwrap version 31004.
Version 1.2.1, 14-Nov-2006
Updated to include Conwrap version 31005.
Conwrap Readme
=============================================================================
Console Wrapper/Extender version 31005
=============================================================================
* About the console wrapper and extender
The console wrapper, combined with its associated extender, enables
WinBatch scripts to interact with the command-line console in the same
way as native command-line applications. The script can read from the
standard input file (STDIN) and write to the standard output (STDOUT)
and standard error (STDERR) files. Additionally, the script can write
to the console window and read input from the console.
The wrapper is a command-line executable that runs a designated WinBatch
script. The wrapper continues to run as long as the script does, and
takes care of passing data between the script and the console/standard
files. The script interfaces with the wrapper via the extender, which
provides a host of functions for reading and writing data.
* Using the console wrapper
There are two ways to use the console wrapper. The first way is to use
the console wrapper executable, conwrap.exe. The second way is to use
the PackTemp utility with the /C switch to pack the program using the
console wrapper stub.
* The console wrapper executable
The executable named conwrap.exe is a wrapper program that will in turn
run a WinBatch file. There are two ways to have conwrap.exe determine
the name of the file to run. In the first method, the filename is the
first parameter on the command line. In the second method, the name of
the wrapper executable is modified, which will cause the wrapper to look
for a similarly-named file in the same directory.
When using the first method, the name of the wrapper executable must be
either remain "conwrap.exe", or start with the word "conwrap" (case
doesn't matter). The first parameter can be the path to a WinBatch
script (.WBT, .WBC, or .W32), a compiled WinBatch executable, or the
main WinBatch interpreter (WinBatch.exe).
If you use the name of a script file, then Conwrap will locate the
associated executable (e.g. WinBatch.exe) using the file extension. You
can override what executable is used by creating an environment variable
in the form of CONWRAP_XXX, where XXX is the extension. The environment
variable should specify the full path to the executable that will
execute the script.
Here is an example of using a script file:
conwrap.exe script.wbt param1 param2
Here is an example of using a compiled WinBatch executable:
conwrap.exe script.exe param1 param2
If the main WinBatch interpreter is used, then the next parameter must
be the name of the WinBatch script to run, followed by the actual
parameters. Here is an example of using the main WinBatch executable:
conwrap.exe c:\...\WinBatch.exe script.wbt param1 param2
The second method for using the wrapper executable involves renaming it.
If the name of the wrapper executable starts with anything other than
the word "conwrap", then the wrapper will look for a file in the same
directory with the same name, but with a .WXE extension. This file must
be a WinBatch script that has been compiled to an executable (small or
large EXE). The WinBatch compiler options can be modified so that the
output file ends with the correct .WXE extension. This method does not
support .WBT, .WBC, or .W32 files.
An example scenario for using this method would involve compiling a
WinBatch script as SCRIPT.WXE. In the same directory as SCRIPT.WXE,
there would also be a copy of CONWRAP.EXE, renamed as SCRIPT.EXE. When
SCRIPT.EXE (the wrapper executable) is run, it will look for and run a
file named SCRIPT.WXE in the same directory as itself.
* The console wrapper stub
If the /C switch is used with the PackTemp utility, the resulting
executable will use the console wrapper stub. The stub is nearly
identical to conwrap.exe, except that it extracts the compiled script
(and other optional files) to a temporary directory before running it.
In this case, the compiled script doesn't need to be renamed, because
the file information has been added to the stub itself. Once the script
exits, the stub deletes the temporary directory.
* Command line parameters
Both the wrapper executable and stub will pass all command line
parameters to the compiled script. However, the stub inserts one
additional parameter at the beginning of the sequence to provide
information that would otherwise be unavailable. Reference the
packtemp-readme file for more information.
* The process exit code
When the script exits, both the wrapper executable and stub will set
their exit code to match the exit code returned from the script.
IntControl 1000 can be used to set the exit code within the script.
* Using the extender
To use the extender in a script, add the following line to the
beginning:
AddExtender("wconw34i.dll")
Note that the extender will only function properly if the script was
directly called by the wrapper executable or stub. Thus, it is not
possible to have an intermediate program between the wrapper and the
script.
When AddExtender is called, the extender will attempt to initialize
communications with the wrapper program that called it. If
initialization succeeds, then the cwInitError() function will return 0.
If it fails, the value returned by cwInitError() will an error number.
Thus, the first thing that should be done after adding the extender is
to check the value returned by the cwInitError() function.
The included example script, CWTEST.WBT, demonstrates the use of many of
the functions. Here is one method for running the example script from
the command line:
conwrap.exe cwtest.wbt
=============================================================================
Special precautions:
=============================================================================
* Closing the console window, logging off, or shutting down
Console applications (such as the console wrapper) handle certain events
much differently than standard Windows applications. For example, if the
user closes the console window, either by clicking the close button or
closing it from the taskbar, then the console application is given a
limited amount of time to finish processing and exit before the user is
presented with an option to terminate the application.
The same thing happens when the user logs off or shuts down the system,
in which case the console application may have even less time to respond
(as little as five seconds).
Thus, the console wrapper has little choice but to exit as soon as
possible when one of these events occur. When it does happen, the
wrapper will execute the following sequence:
1) The wrapper will close down communications with the extender. This
causes a couple things to happen:
- Extender I/O functions will fail with error 102 (Parent process no
longer running). Thus, error checking should be used around all
extender I/O functions.
- The cwFlags function can be used to check for this condition
without generating an error. However, this does not eliminate the
need for error checking around I/O functions.
2) The wrapper will wait two seconds for the WinBatch script to exit.
If the script does not exit within this amount of time, then the
wrapper will send a WM_CLOSE message to the script. This message is
usually ignored by WinBatch scripts, but processing can be enabled by
using IntControl 1008. Doing this causes WM_CLOSE messages to be
handled just like Ctrl+Break.
3) The wrapper will wait yet another two seconds for the WinBatch script
to exit. This is used mainly by the console wrapper stub, to give
the script time to exit before attempting to delete the temporary
directory.
* Tips for creating well-behaved console scripts
Considering the above information, a well-behaved console script should
be ready to terminate at any moment. The following tips can be used to
ensure that your script handles things gracefully:
- As mentioned before, use error checking around all extender I/O
functions, either via ErrorMode(@OFF)/LastError() or by trapping
errors.
- If the script has a loop that can run for more than a few seconds
without processing any input, add code inside the loop to check
cwFlags to see if the parent process has terminated.
- Consider enabling the processing of WM_CLOSE messages via IntControl
1008, and setting IntControl 12 to allow the script to be terminated
silently via Ctrl+Break.
- If it's not desirable to allow the script to be terminated without
notice, try to avoid the use of dialog boxes, message boxes, and other
things that temporarily halt script processing.
- Use IntControl 38 to enable silent logging of fatal errors.
- If another program depends on the exit code returned from the script,
set the exit code (using IntControl 1000) early in the script to a
default error value. If the script has to terminate before processing
is finished, then the other program will know an error occurred.
=============================================================================
List of extender functions:
=============================================================================
cwControl( number [, value ] )
Parameters:
(i) number Control item to read/set
(i) value Optional new value for control item
Returns
(i) Value of control item
Use this function to control operation of the extender.
Control item 1 - Line terminator for cwWrite functions
Possible values:
0 - No terminator
1 - CR/LF (default)
2 - LF
3 - CR
4 - Tab
The previous value will be returned if a new value is specified.
Control item 2 - Console input mode
Possible values:
0 - Line input mode (default)
1 - Character input mode
The previous value will be returned if a new value is specified.
In character input mode, the function will return as soon as the user
has typed a character. Typing Ctrl+C will not set the cwCtrlC() flag.
Instead, the read function will return ASCII character 3. Ctrl+Z will
return ASCII character 26. Also, auto-echo is disabled in character
input mode. Special control characters such as function keys and arrow
keys are not handled and will not return a value.
Note that this setting only affects console input (including STDIN if it
has not been redirected from the console). It has no effect on disk
file or pipe input, which are always set to line input mode.
=============================================================================
cwCtrlBreak( [ clear ] )
Parameters:
(i) clear @TRUE = clear Ctrl+Break flag after reading
@FALSE (default) = don't clear flag after reading
Returns:
(i) 0 - Ctrl+Break has not been pressed
nonzero - Ctrl+Break has been pressed
Use this function to determine if Ctrl+Break has been pressed in the console.
If you pass @TRUE for the clear parameter, the flag will be cleared after it
is read (if it had been set). Otherwise, cwCtrlBreak will return the same
value the next time it is called.
Note that NT based systems handle Ctrl+Break differently then Windows 95
systems. On NT systems, when the user presses Ctrl+Break in the console, the
signal is also passed to the WinBatch script, and should be handled with
IntControl(12). On Windows 95/98 systems, the WinBatch script doesn't
receive the Ctrl+Break signal.
=============================================================================
cwCtrlC( [ clear ] )
Parameters:
(i) clear @TRUE = clear Ctrl+C flag after reading
@FALSE (default) = don't clear flag after reading
Returns:
(i) 0 - Ctrl+C has not been pressed
nonzero - Ctrl+C has been pressed
Use this function to determine if Ctrl+C has been pressed in the console.
If you pass @TRUE for the clear parameter, the flag will be cleared after it
is read (if it had been set). Otherwise, cwCtrlC will return the same value
the next time it is called.
=============================================================================
cwErrorMsg( [ number ] )
Parameters:
(i) number Error number from cwInitError() or LastError()
Returns:
(s) Text associated with the specified error number
Use this function to get the text associated with an error number returned
from the cwInitError() extender function or the LastError() WIL function.
=============================================================================
cwFlags( mask [, clear ] )
Parameters:
(i) mask Specifies which flags to check:
1 = Ctrl+C pressed.
2 = Ctrl+Break pressed.
4 = Parent process terminated.
Combine flags with logical OR (|).
(i) clear @TRUE = clear Ctrl+C or Ctrl+Break flag after reading
@FALSE (default) = don't clear flag after reading
Returns
(i) Status of flag(s).
Use this function to check the status of several flags maintained by the
extender.
This function can be used as an alternative to the cwCtrlC or cwCtrlBreak
functions for checking the status of those keys.
When specifying the mask for which flags to check, combine the values using
the logical OR operator (|). For example, if you want to check all three
flags, the mask would be 1 | 2 | 4, resulting in a value of 7.
If none of the flags specified in the mask were set, then the return value
will return zero. If one or more of the flags were set, then the return
value will be a combination of one or more of the flags. To check individual
flags in the result, use the logical AND operator (&). For example, if the
return value was in variable X, then (X & 2) would be non-zero if the
Ctrl+Break flag was set.
If flag 4 is set, indicating the parent process has exited, special care
should be taken to finish processing and exit as soon as possible. See the
Special Precautions section above.
If you pass @TRUE for the clear parameter, the Ctrl+C and/or Ctrl+Break flag
will be cleared after it is read (if it had been set and was included in the
mask). Otherwise, the flag(s) will return the same value the next time the
function is called. The flag indicating that the parent process has exited
cannot be cleared.
=============================================================================
cwInitError()
Parameters:
none
Returns:
(i) Initialization error code
Use this function to see if an error occurred during extender initialization.
The function will return 0 if initialization was successful.
If initialization failed, then none of the extender functions will work
except this one, cwErrorMsg(), and cwSystemError(). Other extender functions
will trigger an error.
The value of cwSystemError() may be set to provide extended debugging
information.
The value returned by this function can be used with cwErrorMsg to get a
description of the error.
=============================================================================
cwIsConsole( file )
Parameters:
(i) file @cwIn, @cwOut, or @cwErr
Returns
(i) 0 - File is not attached to console
nonzero - File is attached to console
Use this function to check if the STDIN, STDOUT, or STDERR files are attached
to the console.
If the function returns a nonzero value, then the associated file is attached
to the console. For STDIN, this means that the user will be prompted to type
input. For STDOUT and STDERR, this means that output will go to the console
window.
=============================================================================
cwOutputHandle( file )
Parameters:
(i) file @cwOut, @cwErr, or @cwCon
Returns
(i) Handle
Use this function to obtain a handle that can be passed to system API calls
(e.g. via DllCall). Data written to the handle will go to the respective file
(STDOUT, STDERR, or the console window). The handles can only be used for
output, typically via WriteFile.
=============================================================================
cwRead( file )
Parameters:
(i) file @cwIn or @cwCon
Returns
(s) Line of input
Use this function to read a line of input from STDIN or the Console.
If input is coming from a file or pipe, then the function acts very much like
the FileRead() WIL function. It will return the string *EOF* when end of
file is reached, or the pipe is broken.
If input is coming from the console, and line input mode is enabled, then the
behavior varies depending on the OS platform:
Windows 95/98:
If the user presses Ctrl+Z, input ends immediately and the function
returns *EOF*.
If the user presses Ctrl+C, nothing happens, but the cwCtrlC() function
will return @TRUE the next time it is checked.
Windows NT/2000/XP/2003:
If the user types Ctrl+Z at the beginning of a line and presses Enter,
the function returns *EOF*.
If the user presses Ctrl+C, input ends immediately and the function
returns *EOF*. The cwCtrlC() function will return @TRUE the next time
it is checked.
Reference the topic on cwControl(2) for information on changing the console
input mode.
=============================================================================
cwReadCon()
Parameters:
none
Returns
(s) Line of input.
Calling this function is the same as calling cwRead(@cwCon)
=============================================================================
cwReadIn()
Parameters:
none
Returns
(s) Line of input.
Calling this function is the same as calling cwRead(@cwIn)
=============================================================================
cwSystemError()
Parameters:
none
Returns
(i) The last system error that occurred.
Use this function to obtain extended error information if an error occurs
while calling a Console Wrapper extender function.
The error code returned is the value returned by the GetLastError() API call.
=============================================================================
cwType( file )
Parameters:
(i) file @cwIn, @cwOut, or @cwErr
Returns
(i) File type (see below)
Use this function to check the file type for STDIN, STDOUT, or STDERR.
The function will return one of the following values:
0 - File type could not be determined (rare)
1 - Disk file
2 - Character file (LPT, console, etc.)
3 - Pipe
File types can vary depending on whether or not input/output was redirected
when the program was executed.
=============================================================================
cwWrite( file, text [, flag ] )
Parameters:
(i) file @cwOut, @cwErr, or @cwCon
(s) text Text to output
(i) flag @FALSE - don't add terminator to line
@TRUE (default) - add terminator if set
Returns:
(i) 0 - Normal return value
nonzero - Broken pipe
Use this function to write output to STDOUT, STDERR, or the Console.
If output was redirected to a pipe, then this function will return a nonzero
value if the process on the other end of the pipe terminated or closed the
pipe handle.
=============================================================================
cwWriteCon( text [, flag ] )
Parameters:
(s) text Text to output
(i) flag @FALSE - don't add terminator to line
@TRUE (default) - add terminator if set
Returns:
(i) 0 - Normal return value
nonzero - Broken pipe
Calling this function is the same as calling cwWrite(@cwCon, ... )
=============================================================================
cwWriteErr( text [, flag ] )
Parameters:
(s) text Text to output
(i) flag @FALSE - don't add terminator to line
@TRUE (default) - add terminator if set
Returns:
(i) 0 - Normal return value
nonzero - Broken pipe
Calling this function is the same as calling cwWrite(@cwErr, ... )
=============================================================================
cwWriteOut( text [, flag ] )
Parameters:
(s) text Text to output
(i) flag @FALSE - don't add terminator to line
@TRUE (default) - add terminator if set
Returns:
(i) 0 - Normal return value
nonzero - Broken pipe
Calling this function is the same as calling cwWrite(@cwOut, ... )
=============================================================================
Error codes
=============================================================================
101 Extender did not initialize successfully
Will be returned by all I/O functions if initialization
failed. Check cwInitError before using I/O functions to avoid
this error. No more I/O can be processed if this error
occurs.
102 Parent process no longer running
May occur during I/O functions if the wrapper terminated. No
more I/O can be processed if this error occurs. Script should
exit if this error is encountered.
103 Invalid file number for this function.
An invalid file number was used with cwWrite or cwRead. I/O
can continue if this error occurs, but the script should be
checked to find out why an invalid file number was used.
104 Read operation failed
A system error occurred during a read operation. Use
cwSystemError to get the system error number. It may be
possible for I/O to continue after this error, but it is
recommended that the script exit.
105 Write operation failed
A system error occurred during a write operation. Use
cwSystemError to get the system error number. It may be
possible for I/O to continue after this error, but it is
recommended that the script exit.
106 Error writing IPC command
System error while sending a command to the wrapper. Use
cwSystemError to get the system error number. It may be
possible for I/O to continue after this error, but it is
recommended that the script exit.
107 Error reading IPC result
System error while reading command result from wrapper. Use
cwSystemError to get the system error number. It may be
possible for I/O to continue after this error, but it is
recommended that the script exit.
108 Error writing IPC data
System error while sending data to the wrapper. Use
cwSystemError to get the system error number. It may be
possible for I/O to continue after this error, but it is
recommended that the script exit.
109 Error reading IPC data
System error while reading data from the wrapper. Use
cwSystemError to get the system error number. It may be
possible for I/O to continue after this error, but it is
recommended that the script exit.
110 Failed to allocate memory for command
System error while allocating memory for sending data. Use
cwSystemError to get the system error number. It may be
possible for I/O to continue after this error, but it is
recommended that the script exit.
The following errors may be returned by cwInitError:
111 OpenFileMapping failed (must start via wrapper program)
System error while opening file mapping created by wrapper.
Likely indicates that the console wrapper was not used to run
the script.
112 MapViewOfFile failed
System error while trying to map data into memory.
113 Version mismatch in initialization data.
The version information passed from the wrapper is not
compatible with the extender's version.
114 Failed to allocate stdin input buffer
System error while allocating memory.
115 Failed to allocate console input buffer
System error while allocating memory.
116 Failed to allocate IPC buffer
System error while allocating memory.
=============================================================================
Change log
=============================================================================
Version 31001, 07-Jun-2004
First release
Version 31002, 11-Jun-2004
Added cwControl item 2 to allow changing console input mode.
Added cwCtrlBreak function to check if Ctrl+Break has been pressed.
Disk file/pipe input is now handled directly by the extender instead of
passing through the console wrapper first.
Version 31003, 24-Aug-2005
Added cwFlags function.
Modified wrapper's Close/Logoff/Shutdown handler to send a WM_CLOSE
message to the child process (which can optionally be ignored).
Version 31004, 31-Oct-2006
Added cwOutputHandle function.
Version 31005, 14-Nov-2006
Modified the way the target executable is discovered. If the wrapper
executable filename starts with "conwrap", then the first parameter of
the command line is used as the target file name. Otherwise, the
wrapper executable name is used with the extension changed to .WXE.
The wrapper now provides more verbose information in the event of a
fatal error.
Article ID: W16865
File Created: 2019:08:14:08:57:56
Last Updated: 2019:08:14:08:57:56