Hi Rainer, > I am maintaining XP and Vista clients too. That's why I made some > enhancements for full Vista and also 64-bit support in wpkg.js. Any jolly good they are, too! The Vista machines are working well with WPKG. > You're right - I never tried the "logon delay" feature on Vista. So you say I > don't have to try ;-) No errors or anything - just no display! > In fact I don't like the logon delay feature so much as I do not want to keep > users waiting. I am installing the package in background while the user logs > on. My experience is that WPKG finishes its work (even when some smaller > packages are installed) before the user actually gets the chance to run some > applications. > And even if the user already started applications - in worst case > installation fails and it will be re-tried on next start until it succeeds. > Some (most?) installers can also handler the case when the application is > currently running. Either by closing it or by scheduling file replacements > for next windows start. I've found some problem with that approach when updating virus scanners, for example, which require reboots. Our users get a bit upset when the machine starts to reboot while they're working! I think I'd prefer to inconvenience the users by delaying them starting work than interrupting them when they've started - but that's just my view. > As already outlined when we discussed about displaying some progress > information when using logon delay: I did not find a way to use named pipes > by JScript. There seems to be no way as it is impossible to open a named pipe > by JScript. That's why WPKG 1.1 is writing status information to STDOUT in > order to allow re-directing of STDOUT and parsing its output. That's > currently the most reliable way I was able to figure out. That method would be possible too. There's a page http://www.codesegment.com/sms_studio_help/Help/Tutorial/Samples/How%20to%20Send%20a%20Message%20through%20Named%20Pipe.htm on using Named Pipes through VBScript, so I'd imagine the same approach would work through JScript since they both use WSH. > Well if we find a better way it might be quite simple to implement. Current > WPKG architecture would allow to exchange the STDOUT printing with any output > module. But remember, it needs to be very reliable and stable - I will not > accept proposals which require "hacks" or external programs or other > unreliable and complicated work-arounds as I consider this feature to be much > less important than stability. I'm hoping that using named pipes would be quite easy: try { writeToNamedPipe(msg); } catch (e) { // Oh well, it didn't work. } We might need an equivalent of dinfo() to indicate messages for the user and perhaps some configuration about what messages ought to be sent. (I'd like lots of detail but I suspect others wouldn't!) At the moment, though, I'm concentrating on the code to display the message box and assuming that we can get the information into the named pipe easily enough, either through wpkg.js itself or by having something parsing STDOUT. > I am quite sure a thread could pick up the messages fast enough. However > named pipes might not work - see above. Capturing WPKG STDOUT to a buffer > might work better. It's more that there's no way of removing the message box once it's been sent to the screen (I think - corrections welcome if I'm wrong about that), so it's possible that the message box thread would pick up a message which cannot be displayed while a previous message is being displayed and then gets a third message which over-writes the second. I think ideally we might try to use the CreateProcessAsUser API and get a window where we can update things in real time, but that would be a job for later / someone who knows more than I do about this sort of coding! Yours, Frank |