20 replies to this topic

[homes32]

File Name: BGInfo
File Submitter: homes32
File Submitted: 15 Aug 2011
File Updated: 18 Jan 2012
File Category: App scripts

BgInfo automatically displays relevant information about a Windows computer on the desktop's background, such as the computer name, IP address, service pack version, and more. This script also adds a feature not native to BGInfo; The ability to refresh the screen at a user defined interval.

Known Issues:

• Showing the IP address will not work on win7 x64. this is a known issue with BGInfo.exe

Click here to download this file

[sbaeder]

Question: Is the networking issue a function of the tool? Or something related to the WoW64 stuff (implied by this thread... http://social.techne...-09ebbb152b8d/
Especially since on a FULL x64 "host" it works just fine...Related to this is an anomoly, and again, may be due to the way the PE handles the WOW64 stuff..

I have a custom field that gives me the time the PE was created, so I can make sure the right ISO is being tested...on the x64 version of the PE, it can't find the file (winpeshl.ini)....I can "see it" in the file explorer of the OS, but not the internal file open dialog of bginfo.exe tool...this is why I think it might be an issue with the tool, and how it handles the whole x64 environment...

But, thanks for listing the networking things as a "glitch" - I thought I was going "batty"...Maybe it needs expansion to cover all things x64 related - i.e. some things just aren't there since the tools wasn't compiled for it)...

Finally, just a note here as well, on the X64 PE, if there is no wallpaper bitmap, you will get a warning message about the failure to copy the bitmap... No big deal...just put in a bitmap!

Thanks for a great script!!!!

[homes32]

Question: Is the networking issue a function of the tool? Or something related to the WoW64 stuff (implied by this thread... http://social.techne...-09ebbb152b8d/
Especially since on a FULL x64 "host" it works just fine...Related to this is an anomaly, and again, may be due to the way the PE handles the WOW64 stuff..

I have a custom field that gives me the time the PE was created, so I can make sure the right ISO is being tested...on the x64 version of the PE, it can't find the file (winpeshl.ini)....I can "see it" in the file explorer of the OS, but not the internal file open dialog of bginfo.exe tool...this is why I think it might be an issue with the tool, and how it handles the whole x64 environment...

It seems to be program related. there are lots of reports that network info won't show up on "normal" 2008/7 x64 and never shows up in PE. although PE in general seems to confuse BGInfo sometimes. part of the purpose of RunBGInfo.exe

Finally, just a note here as well, on the X64 PE, if there is no wallpaper bitmap, you will get a warning message about the failure to copy the bitmap... No big deal...just put in a bitmap!

most likely because ChrisR modified the default .bgi embedded in the script. if you click the customize button and then click the background button and make sure the radio option is set to Copy users wallpaper settings. this should fix the issue for you.

[homes32]

ps. looks like chrisR also modified runbginfo file copy in such a way that will cause problems if you are not using the standard background pic/location... best to download the unmodified script. current version is v.7c located above and should work well.


@ChrisR

try the script above and see if it works for you. I remember we talked awhile ago about the issues with x64 and manually specifying the path in bginfo.bgi
this should not be necessary anymore with the never version of runbginfo.exe

[Wonko the Sane]

I think I will reiterate :
http://reboot.pro/8590/page__st__22


Would Samurize run on 7 / PE 3?
And on 64 bit?


Wonko

[homes32]

I think I will reiterate :
http://reboot.pro/8590/page__st__22


Would Samurize run on 7 / PE 3?
And on 64 bit?


Wonko

it may...I haven't tested recently. its probably worth looking into again.
the reason I made the BGInfo script in the 1st place was its easy for nonfimilar users to customize (via script interface button) and pretty much an industry standard. although I share you sedaments and would rather see a better solution. frankly as popular as BGInfo is in the IT world I'm surprised that it hasn't been updated in so long despite the growing list of issues it has on never OS's

[sbaeder]

It seems to be program related. there are lots of reports that network info won't show up on "normal" 2008/7 x64 and never shows up in PE. although PE in general seems to confuse BGInfo sometimes. part of the purpose of RunBGInfo.exe

The "preview" works fine on my x64 OS (shows the actual networking on my "host" machine, which is Win7/SP1/X64, so it probably has something to do with PE???

most likely because ChrisR modified the default .bgi embedded in the script. if you click the customize button and then click the background button and make sure the radio option is set to Copy users wallpaper settings. this should fix the issue for you.

Actually, the weird thing was that the "explorer" could see all the files in the directory just fine, but the BGInfo tool couldn't - again, maybe due to the whole WoW and PE thing...Not a big issue, but something to look at more...

I think I will reiterate :
http://reboot.pro/8590/page__st__22

Would Samurize run on 7 / PE 3?
And on 64 bit?

Yes, when I looked to alternative tools to BGInfo, this poped up...but it looks like while it is very powerful, it isn't being actively supported either So I was also thinking of looking at WPInfo, but it uses .net and more likely DeskTopInfo - BUT, I totally agree with the concepts Homes stated of nice GUI to configure and easy for "noobs"

Well..WPInfo has nice GIU, but is a bit buggy...it has to have a pointer to a folder with the background bitmap in it, and the way it "finds" it is just plain screwy! It also has a bug in the preview menu entry (in file menu) doesn't work, but the icon in the menu bar does! If it weren't for the whole .net 3.5 runtime, it MIGHT be useable, since it's simple.

On the other hand, DeskTopInfo creates some nice graphics, and runs in real time - BUT has no config GUI - just uses an INI file, so I suppose a scripted approach could be done with a WinBuilder GUI to add SIMPLE things...May look at that further, but for now, both seem like a "bust"...

Also looked a bit at Samuarize, and MAYBE it would be an OK choice - has a GUI, but it's rather "complex" (i.e. has powerful options, so may be difficult for a NOOB)...More I think about it, a simple set of check boxes in WInbuilder could generate the ini file for DeskTopInfo....

Scott

[pscEx]

// Note: it is normal for the startup countdown and auto refresh not to work correctly when running in qEmu
// this is a bug in qEmu with CPU freq.

In multiPE I do not have any troubles with qEmu.

can you explain in detail what fails and how I can test?

Peter

[Wonko the Sane]

@psc

WHO/WHERE you quoted from?


Wonko

[pscEx]

Comment in the script.

Sorry, for insiders no issue, But for the rest of the world I wrote something ununderstandable.

Peter

[homes32]

On the tooltip in the lower right corner that says "Waiting nn:nn for PENetwork.exe....." the countdown will behave erraticly in Qemu...
also the autorefresh functinoality does not work due to the same background issue.

the issue seems to be related to the autoit function TimerDiff() returning odd values when running under QEmu
TimerDiff Returns the time difference (in milliseconds) from a previous call to TimerInit()
TimerInit uses BOOL WINAPI QueryPerformanceCounter() to return a Timstamp in ms

some other topics I found trying to resolve the issue
http://www.autoitscr...howtopic=115612
http://www.autoitscr...oit/ticket/1082
http://www.autoitscr...howtopic=105761

the current implemation for the countdown is:

Func PreStart()

Local $diff, $secondsRem, $minutes, $Countdown

Local $ms = 60000 ; timout value in milliseconds.

Local $timer = TimerInit()

Local $GWL_STYLE = -16 ; Used with GetWindowLong() to retrieve the window styles.

Local $Programs[2] ; Array of programs to wait for

$Programs[0] = "PENetwork.exe"

$Programs[1] = "penetcfg.exe"

; try and locate the system tray and pick our position

$aTipLoc = _Toast_Locate(245, 55) ; approx width and height of tip

ToolTip("Starting BGInfo", $aTipLoc[0], $aTipLoc[1], "Starting BGInfo...", 1, 0)

Local $hToolTip = WinGetHandle("[TITLE:Starting BGInfo; CLASS:tooltips_class32]", "") ; Text is Title for a tooltip

_WinAPI_SetWindowLong($hToolTip, $GWL_STYLE, BitOR(_WinAPI_GetWindowLong($hToolTip, $GWL_STYLE), $TTS_CLOSE)) ; put [X] on tip

; wait for network programs to finish so we can display the IP address.

For $i = 0 To UBound($Programs) - 1 Step 1

  If ProcessExists($Programs[$i]) Then

   ;wait for timer to expire

   While TimerDiff($timer) < $ms

	$seconds = TimerDiff($timer) / 1000	

    $diff = $seconds - ($ms / 1000)

	$minutes = Int($diff / 60) * - 1

	$secondsRem = ($diff - ($minutes * 60)) * - 1

	$Countdown = StringFormat("%02d", $minutes) & ":" & StringFormat("%02d", $secondsRem)

	Sleep(500) ; reduce flicker

	_GUIToolTip_UpdateTipText($hToolTip, 0, 0, "Waiting " & $Countdown & " for " & $Programs[$i] & " to finish.")

	If Not ProcessExists($Programs[$i]) Then ExitLoop ; see if process terminated before timeout reached

   WEnd

  EndIf

Next

;tooltip is hidden, not closed on [X] click

If _GUIToolTip_ToolExists($hToolTip) Then _GUIToolTip_Destroy($hToolTip)

EndFunc   ;==>PreStart

and for AutoRefresh wait loop

While 1

  If TimerDiff($timer) >= $RefreshInterval Then

   StartBGInfo()

   $timer = TimerInit() ; reinit the timer.

  EndIf

.....

[pscEx]

Where TimerDiff and friends come from?

I do not have any autoit programs in my project!

My project only starts any emulator, in this case qEmu.

For me it currently looks like there is a problem of a / some certain project(s) with selfmade autoit functions, which are not understood by qEmu as intended.
I assume that these functions are starting at PE boot.

As known, this behavour is at least time wasting, IMHO bad developing style.
A good programmed and structured project knows at build time EVERYTHING necessary and can build the final PE accordingly.
Any shortcut, association, startup, RegAddBoot, etc. generated / executed during boot, wastes on EVERY boot a lot of time.

That is not really a bug of qEmu, but rather some bad information given to qEmu by the project.

Peter

BTW: I made a small change in your app. Now it can optionally appear in the first screen after boot.
As seen, you tried this, too, but it is commented out. IMO that depends on the "TimerDiff and friends" functionality.

If you pay with a bottle of good wine, you may use my working script!

OFF TOPIC:
[German]Schuster, bleib bei Deinem Leisten![/German]
In English something like: "Shoemaker, stay with your strips"
Is the same advise valid for tailors, carpenters, bakers, ... ???

[Wonko the Sane]

If you pay with a bottle of good wine, you may use my working script!

Does your .script provide the:

This script also adds a feature not native to BGInfo; The ability to refresh the screen at a user defined interval.

added functionality?


Wonko

[pscEx]

Surely not!

I offer a working modification, not a script depending on some baker's creations.

Peter

[Wonko the Sane]

Surely not!

I offer a working modification, not a script depending on some baker's creations.

I don't get it.
As seen from outside whatever homes32 provides is:

• BGINFO working
• added functionality to it working allright BUT not working properly under Qemu

A bettering for it might be IMHO:

• BGINFO working
• added functionaluty to it working AND working properly under Qemu also

If I get it right what you suggest is instead :

• BGINFO working (exactly as homes32's script does, BUT through a "better" written .script)

Wonko

[sbaeder]

On the issue with QEMU and "timers"...this is common in some virtual environments where the "clock" is virtual. The "clock" used by the virtual machine's operating system is based on counting interrupts and ticks from the virtual hardware, which makes it susceptible to clock skew when the virtual machine or its host is under significant load. If the host CPU is too busy to service the VM's clock, it can get out of sync with the host (or other VM's)...afterall, it is only software - and the OS's involved are not designed for "real time" operation.

Scott

[homes32]

Where TimerDiff and friends come from?

For me it currently looks like there is a problem of a / some certain project(s) with selfmade autoit functions, which are not understood by qEmu as intended.
I assume that these functions are starting at PE boot.

TimerInit() and TimerDiff() are native functions built into autoit. they do not start at boot. only return a value when called.
I am told by developers that TimerInti() uses the windows API QueryPerformanceCounter() to get a tick count from the time of boot.
so it would seem Qemu has issues in how its CPU frequency.

VMWare and virtualbox both work fine as do every physical system I have run on.

EDIT:
put together some code to illistrate the issue:

TimerInit() and TimerDiff() are internal autoit functions
_Timer_Init() and _TimerDiff() are reproductions using the same method as the above functions. the code is below.
compile and look at the output in windows and then in qemu to see the issue.

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****

#AutoIt3Wrapper_UseX64=n

#AutoIt3Wrapper_Change2CUI=y

#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****





$Timer = TimerInit()

$t2 = _Timer_Init()

While True

	ConsoleWrite("TimerInit() Start Value..: " & $Timer & "  TimerInit() Current Value..: " & TimerInit() &   "  TimerDiff..: " & TimerDiff($Timer) & @CRLF)

	; the following will be a few ms off due to delay between consoleWrite funcs but still recognizably close to the above

    ; so it is appearent that the reproduced functions use the same method as the Internal autoit functions

	ConsoleWrite("_Timer_Init() Start value: " & $t2 &	"  _Timer_Init() Current Value: " & _Timer_Init() & "  _Timer_Diff: " & _Timer_Diff($t2) & @CRLF)

	Sleep(100)



WEnd



; #FUNCTION# ====================================================================================================================

; Name...........: _Timer_Diff

; Description ...: Returns the difference in time from a previous call to _Timer_Init

; Syntax.........: _Timer_Diff($iTimeStamp)

; Parameters ....: $iTimeStamp - Timestamp returned from a previous call to _Timer_Init().

; Return values .: Success - Returns the time difference (in milliseconds) from a previous call to _Timer_Init().

; Author ........: Gary Frost, original by Toady

; Modified.......:

; Remarks .......:

; Related .......: _Timer_Init

; Link ..........:

; Example .......: Yes

; ===============================================================================================================================

Func _Timer_Diff($iTimeStamp)

	Return 1000 * (__Timer_QueryPerformanceCounter() - $iTimeStamp) / __Timer_QueryPerformanceFrequency()

EndFunc   ;==>_Timer_Diff



; #FUNCTION# ====================================================================================================================

; Name...........: _Timer_Init

; Description ...: Returns a timestamp (in milliseconds).

; Syntax.........: _Timer_Init()

; Parameters ....:

; Return values .: Success - Returns a timestamp number (in milliseconds).

; Author ........: Gary Frost, original by Toady

; Modified.......:

; Remarks .......:

; Related .......: _Timer_Diff

; Link ..........:

; Example .......: Yes

; ===============================================================================================================================

Func _Timer_Init()

	Return __Timer_QueryPerformanceCounter()

EndFunc   ;==>_Timer_Init



; #INTERNAL_USE_ONLY# ===========================================================================================================

; Name...........: __Timer_QueryPerformanceCounter

; Description ...: Retrieves the current value of the high-resolution performance counter

; Syntax.........: __Timer_QueryPerformanceCounter()

; Parameters ....:

; Return values .: Success - Current performance-counter value, in counts

;				  Failure - -1

; Author ........: Gary Frost

; Modified.......:

; Remarks .......:

; Related .......: __Timer_QueryPerformanceFrequency

; Link ..........: @@MsdnLink@@ QueryPerformanceCounter

; Example .......:

; ===============================================================================================================================

Func __Timer_QueryPerformanceCounter()

	Local $aResult = DllCall("kernel32.dll", "bool", "QueryPerformanceCounter", "int64*", 0)

	If @error Then Return SetError(@error, @extended, -1)

	Return SetExtended($aResult[0], $aResult[1])

EndFunc   ;==>__Timer_QueryPerformanceCounter



; #INTERNAL_USE_ONLY# ===========================================================================================================

; Name...........: __Timer_QueryPerformanceFrequency

; Description ...: Retrieves the current value of the high-resolution performance counter

; Syntax.........: __Timer_QueryPerformanceFrequency()

; Parameters ....:

; Return values .: Success - Current performance-counter frequency, in counts per second

;				  Failure - 0

; Author ........: Gary Frost

; Modified.......:

; Remarks .......: If the installed hardware does not support a high-resolution performance counter, the return can be zero.

; Related .......: __Timer_QueryPerformanceCounter

; Link ..........: @@MsdnLink@@ QueryPerformanceCounter

; Example .......:

; ===============================================================================================================================

Func __Timer_QueryPerformanceFrequency()

	Local $aResult = DllCall("kernel32.dll", "bool", "QueryPerformanceFrequency", "int64*", 0)

	If @error Then Return SetError(@error, @extended, 0)

	Return SetExtended($aResult[0], $aResult[1])

EndFunc   ;==>__Timer_QueryPerformanceFrequency

[sbaeder]

TimerInit() and TimerDiff() are native functions built into autoit. they do not start at boot. only return a value when called.
I am told by developers that TimerInti() uses the windows API QueryPerformanceCounter() to get a tick count from the time of boot.
so it would seem Qemu has issues in how its CPU frequency.

VMWare and virtualbox both work fine as do every physical system I have run on.

This makes sense, since they are both more "industrial" strength, although Qemu is now the core tech inside KVM on Linux...Even VMWare can have issues as I mentioned above, which was on older versions of Red Hat Linux...Newer versions of RH worked better - less reliance on the "Tick" in the kernel...

(by the way, nice example )

[:ck!:]

well, i use the 'PE Build Time' function, on my Win7PE_SE build.
'PE Build Time' currently points to the (file)date of "%Windir%SYSTEM32CONFIGSAM"
but this doesent work,
the filedate for SAM is not set to the build date / time.
just point to i.e. "%Windir%SYSTEM32CONFIGSYSTEM" to fix this.

@all:
could be done, before build, with the "Customize" button.
Costomize > Fields, Custom... > select "PE Build Time" and edit it

@homes32; please update

[homes32]

well, i use the 'PE Build Time' function, on my Win7PE_SE build.
'PE Build Time' currently points to the (file)date of "%Windir%SYSTEM32CONFIGSAM"
but this doesent work,
the filedate for SAM is not set to the build date / time.
just point to i.e. "%Windir%SYSTEM32CONFIGSYSTEM" to fix this.

@all:
could be done, before build, with the "Customize" button.
Costomize > Fields, Custom... > select "PE Build Time" and edit it

@homes32; please update

good idea. I'll get this released later today.
new version v9a on download center.

cheers!
Homes32

[Richardxtc]

Hi

 

I am using BGinfo to fetch data from a text file that gets updated every day at 9 oclock. However the  BGinfo i have does not have a refresh option. 

 

I read that yours can set a user refresh interval...

 

I tried downloading your file but it just downloads as a script file and then i dont know what to do with it from there. Please can you reupload or post the file here for download...

 

Regards