Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Homes32

Pages: [1]
PEBakery / Feature Request: StdErr & Stdout when using ShellExecute
« on: December 13, 2017, 03:28:26 PM »
On my wish-list since "forever" has been a way to redirect stdout/stderr into the builder, or at least log the output without using tricks like running from .cmd/.bat using redirection or using an external app to pipe them off and tee the output to another file for programs that don't write their own logs.

I hate with the fury of a thousand suns when applications/console windows/etc popup during a build, steal focus, annoy me while I'm trying to work on something else, etc. My brain likes to be busy, so I usually run the builder in the background and work on something else in the meantime. However some applications do display useful information while running (makeiso is a good example), so developers feel the need to run them "unhidden".

I see several possible options:

1. Always log stdout/stderr to the log
2. Publish the current contents of stderr/stdout to a small text area on the progressUI possibly under the messages section. This would be useful for programs like makeiso, 7z, etc that show progress that may be useful or entertaining. Also output to log. [See attached screen mockup for a crude example.]
3. Global builder setting to toggle logging of stdout/stderr
4. Add an optional argument to shellexecute telling PeBakery what to do with stdout/stderr
5. Return the streams in a variable for the developer to deal with. (I don't see much value in this. double yuck if the program has a large output this could cause unwanted slowdowns/hangs)

I prefer option #2  :smile:

This could possible cause a small amount of overhead reading the stream and flushing it to the log (as with any logging action), but I would much rather have everything in one spot if possible.
real-time reading of the streams would be preferred to just collecting them in a buffer and dumping them the log at the end of the process, to avoid having the builder to hang if the called program has a large amount of output.

Discussion is welcome. If something solid can be agreed on I will submit a ticket to the tracker for future development.

Forum Support / Attachment Error
« on: February 27, 2017, 02:20:12 PM »
When trying to attach a file to a PM I get the following error when sending the message

The attachments upload directory is not writable. Your attachment or avatar cannot be saved.

The send fails and I get the message regardless of whether I have checked "Save a copy in my inbox"

LiveSystem pro / Getting started questions
« on: February 20, 2017, 01:40:28 PM »
Please excuse me if these questions have already been answered somewhere. I'm a native English speaker so the German forums are hard to follow sometimes.

A few questions as I'm experimenting with LSP.

  • Is there planned support for attachments/embedded files?
  • Are feature requests/fixes/but submission welcome and if so where should they be posted
  • What is the dev process for LSP? is it just kare in his freetime or is it a collaborative effort?
  • Projects have both a and Project.cfg - The 2 files are nearly identical but the editor only opens what is the purpose of Project.cfg?

Thanks :)


Development and code snippets / ClearLock [BETA TESTING]
« on: December 23, 2011, 09:10:25 AM »
ClearLock 1.5.0 is ready for testing!

changes include:
Code: [Select]
Fixed bug where taskman could be accessed during a lockout
fixed sometimes input was enabled on ctrl-alt-del
added blacklist config
re-write of config GUI
more config for lock message appearance
re-write password hashing to use non-reversable encryption. no more cleartext pw in memory!
better multi-monitor support

play around and let me know if something is broke or you have suggestions/requests!
use /config to access the config gui

Merry Christmas!  :newyear:

Macro/Command Development / ScriptInterface
« on: May 09, 2011, 10:08:53 PM »
following discussion here:
features previously provided by GetInterface, WriteInterface, and ShowComponent have been merged into Interface command allowing for greater flexibility, multiple interface support, less complex syntax, and speed improvements.

new syntax:


* ScriptInterface (4.61 kB - downloaded 211 times.)
* Common_Api.script (250.07 kB - downloaded 258 times.)

Hi all!

WimUtil 3.0 is ready for testing.

this is a major overhaul. A big thank you to Nikzzz for allowing me to wreck havoc on his program! :)

  • improved GUI
  • extract wim info to xml or .ini
  • extract file option - AIK3 only
  • x64 bit support
  • better error handling and extensive logging
  • ability to specify a custom wimgapi.dll to use

syntax help is available by starting the program without cmd line parms.

  • Install/Uninstall options for wimfltr.sys have been removed to make this program compliant with MS Licensing

Debug Info
Wimutil returns the following exit codes:
;           0   - Success
;           1   - Syntax Error: The command was used incorrectly, e.g., with the wrong number of arguments, a bad flag, a bad syntax in a parameter, or whatever.
;           2   - File Not Found
;           3   - Path Not Found
;           251 - WIMCapture error
;           252 - WIMCreateFile error
;           253 - Mount Error
;           254 - UnMount Error
;           255 - Stopped by User Request.

debug logging is saved to %Temp%\Wimutil.log
errors are logged in the format: Description ( [Function Return Code], [@Error], [@extended] )
Function Returns vary based on the function and my return a handle, generally if the function returns nonzero it was successful

@Error usually refers to the following values:
;                                  0 - No DLLCall error.
;                1 - Unable to use the DLL file
;                2 - Unknown "return type"
;                3 - "function" not found in the DLL file
;               4 - Bad number of parameters.

@extended usually returns GetLastError()
values can be found here:

the core API has been released here

happy testing!


Known Issues
  • capture gui freezes if you click anywhere during a capture. - this is an autoit issue. a possible workaround is being tested.
  • /Info will cause a hard crash at random I don't know how to fix this or what specifically is causing it. -
  • ????

Version History
Code: [Select]
3.2.0 (09/19/2011) - Homes32
- GetInfo now outputs XML as UTF16 - Thanks to JFX for suggesting.
- Fixed random crash with /info switch. - Thanks JFX

v3.1.3 (6/29/2011) - Homes32
- Fixed a bug where /Boot would never set the iBootFlag to 1
- Added timestamps to log for: capture, getattributes, getxmlinfo

v3.1.2 (05/02/2011) - Homes32
- Rewrote WriteLog()
- Added workaround for mounting with wimgapi.dll 6.0 Read-Only (
- Fixed a bug where loading wimgapi.dll failed if config file exists but api key was not present.
- Minor code cleanups.

v3.1.1 (04/15/2011) - Homes32
- Fixed required # cmd line args for capture
- Changed search order for wimgapi.dll. Program will 1st look for wimutil.ini, if not specified then in @scriptDir, if not exist then look in @SystemDir.
- Extract syntax change. requires a directory path to extract instead of a directory and file name path. the old method is no longer supported. if you want to rename the file after extraction do so manually.
- Extract will now create the destination directory if it does not exist.
- WimUtil.ini now accepts paths relative to @ScriptDir
- Commands are now prefixed with /
- Some tweaks to [Info] section in .ini output.

v3.1.0 (04/08/2011) - Homes32
- Fixed mount path was not created if it didn't exist
- Only check for driver if mount/unmount
- Better error checking for wimgapi.dll and proper driver
- wimutil will look for Wimgapi.dll in @ScriptDir ; value in Wimutil.ini overrides all. you can use @SystemDir in wimutil.ini to specify use wimgapi.dll on local system.
- check wimgapi.dll version and warn if feature not available. (ex. extract/cleanup)
- if no compression option is specified capture uses /xpress compression by default
- added cleanup operation: wimutil.exe Cleanup
- added remount operation: wimutil.exe remount
- description for image capture is no longer mandatory.

Older versions are archived here

Macro/Command Development / Wim Mounting with CAPI
« on: March 02, 2011, 12:23:27 PM »
Hi all,

I finished adding wim mounting/unmounting functions to the CAPI

Supported WimTools are ImageX.exe and WimUtil.exe

Synatx help for the API menu (don't forget to add the APIDef to script.project) and html help for paraglider's chm are also included.

Changes to CAPI
Added new functions for mounting and unmouting wim images via API and changed old clean [UnMountWim] to [Clean_UnMountWim] and set to use new functions.

Functions added: [MountWim] [UnMountWim] [MountWim_ImageX] [UnMountWim_ImageX] [MountWim_WimUtil] [UnMountWim_WimUtil] [MountWim_DISM] [UnMountWim_DISM]

To keep the API as "dumb" and generic as possible The mount tool is decided by the project and is read from Project.ini
Code: [Select]

Example for ImageX
Code: [Select]

Example for WimUtil
Code: [Select]

all file exist, error checking, mount test, and directory creation is done by the API leaving a very small and convenient footprint for .script developers

I have converted the current Win7PE_SE  to run using the API Mount/Unmount and the modified scripts are attached for your testing pleasure. new API commands work very well and cut down a large amount of redundant code used as well as being very easy to use for individual scripts for special mounting/unmounting needs, unlike trying to use functions from 54-Mount.script.

hope you like. let me know if there is something that needs fixed.


Pages: [1]
Powered by EzPortal