[Whimsy]

First, a mere question...
It just occurred to me that IE, and by extention, MSHTA, can access DLL files for some specific resources via the res:// protocol. Since WPI is usually run from a CD (and increasingly as a generic mass application installer), I'm wondering how hard/neat it would be to have WPI read the setup billboard resources. This would be user-configurable (incase you don't want this).
I might give it a crack, but I'm putting this on the table for anyone that wants to give it a go.

And some administrative relief
The other idea I was thinking of included application "tags" - INI files that resided in the slightly higher-level directories that defined applications, instead of putting inside config.js. This would allow WPI to dynamically configure itself for admins, so a particular 'class' of user could have a particular feature set (though to have this idea refined, a brave or foolhardy admin would have to be asked for assistance). There are simple ways of parsing lists of directories and ini files using VBS, which could probably be ported to JS, which would facilitate this.

Example of the above:

[CD-Root]
 -$oem$
 --WPI
 --Nero Burning ROM
 ---Nero Setup.exe
 ---app.wpi
 --Quake 2
 ---QUake 2 setup.ini
 ---app.wpi

The app.wpi file might look like this:

[WPINFO]
name=Winrar 3.42
desc=WinRAR is a 32-bit Windows version of the RAR archiver, the powerful archiver and archive manager. WinRAR compresses up to 30% better than ZIP. WinRAR provides complete support for RAR and ZIP archives and is also able to unpack CAB, ARJ, LZH, TAR, GZ, ACE, UUE, BZ2, JAR, ISO, Z and 7-Zip archives.
cmd1=%cdrom%\\Software\\WinRAR\\wrar342.exe /S
rega=%cdrom%\\Software\\WinRAR\\winrar.reg
dflt=yes
forc=false
cat=Application
ordr=340

I tested the idea in VBScript, and I think it could work, but this was a while ago, and admittedly, not in the context of an HTA file (My intentions were to include it in WPI, but I never get any 'me' time ). I could probably rewrite the code if a tech demo or template was requested. The [pn] part that is currently used in the config.js file would be generated based on how many applications existed in the loop; In psudo-VBS-code, you might see this:

if (app.wpi.fileexists) then
 name[pn] = (parse app.wpi ('wpinfo','name'))
end if
pn++

(of course, the parser could be optimized by storing the entire app.wpi file as a string, which would reduce the need for file openings)

But the big one that no one will agree to (heh)...
I think it might be necessary to consider a move to VBS. Originally, JS was used, because I... well... didn't know VBS that well, and I wanted something that the community could dissect. While JS has served WPI nicely, VBS offers a lot more in the way of features (WPI uses the filesystem object, but larger amounts of the code are using more VBS features). I know it's possible to integrate the two languages, but I think using one language is better than hacking with two, and I don't think it's fair to have developers work between two languages.

I don't think it would be fair to anyone if this was done without putting it on the table first.

Well, that concludes my ideas and suggestions. I'm tired, so I' should go to bed (While watching the Daily Show). What do y'all think?

[hasi001]

Hi Whimsy.

A few annotations to your change requests.

1st: Would good will it do to read resources from DLLs ? Where's the advantage. Wouldn't that lead to the face, that you'd always have to do a full istann, if you want to test WPI ?

2nd: I think you're speaking of different file-sets on deifferent install media. This was asked before - and is possible with current versions of WPI. See this post.

The point, why I am against 'distributed configuration' is, that the forum couldn't help users with poroblems in their configs. Right now it's easy - just post the config.ja and others can help you. But if there are INIs in several directories that would be a hard thing to do. Plus: the information must be given to WPI. It wouldn't spare so many lines of code, if you'd have to write your ini-files. (the only one spared would be the cond[]-property mentioned in the thread above.

Additionally it wouldn't be possible to use the config wizard. So configuration would become a very hard job for unexperienced users.

3rd: What could you do with vbs, that you couldn't also with js ? I know the syntax is easier, but are there any other advantages ?

[Whimsy]

hasi001, on Jan 12 2005, 04:11 AM, said:

Hi Whimsy.

A few annotations to your change requests.

1st: Would good will it do to read resources from DLLs ? Where's the advantage. Wouldn't that lead to the face, that you'd always have to do a full istann, if you want to test WPI ?

2nd: I think you're speaking of different file-sets on deifferent install media. This was asked before - and is possible with current versions of WPI. See this post.

The point, why I am against 'distributed configuration' is, that the forum couldn't help users with poroblems in their configs. Right now it's easy - just post the config.ja and others can help you. But if there are INIs in several directories that would be a hard thing to do. Plus: the information must be given to WPI. It wouldn't spare so many lines of code, if you'd have to write your ini-files. (the only one spared would be the cond[]-property mentioned in the thread above.

Additionally it wouldn't be possible to use the config wizard. So configuration would become a very hard job for unexperienced users.

3rd: What could you do with vbs, that you couldn't also with js ? I know the syntax is easier, but are there any other advantages ?

Well, you woulden't have to do a full install if you set up the directories correctly. As it stands, WPI is in the $oem$\installs\wpi folder, and the bulliton boards are normally kept in the cd-rom\i386 directory. WPI could look in the cdrom\i386 folder, or failing that, the ..\..\..\i386 folder for the backgrounds, which could consolidate the locations of user backgrounds. As for sizing and positioning, this could be handled with the CSS code.

Now that I think about it, it is a long and perhaps complicated project, and it accomplishes little.

---
On the topic of distributed configurations, I figure that this would allow WPI to be slightly more robust. The cond[] option allows for different configs on seperate install mediums, but it doesn't allow for remote installs, for instance. What I'm proposing could allow for administrators to use WMI to decide which groups of users get specific install options over a network.

The configuration wizard would require very little changes; The traversing could happen as a function, and only serves to fill in variables (which would remain the same as defined in config.js). The data would be the same, but come from a different source. If the support were difficult (that is, the associated installation could not complete), it might be as simple as jus tposting the one broken .wpi file. If it were still ambiguous, a configuration compilation utility could be created to copy the configuration files associated with that WPI install (something that might turn out results that look like this)

Debuglog.txt generated on Wednesday January 12 2004 4:50AM
---
(file ..\nero\app.wpi)
[data goes here]
---
(file ..\winrar\app.wpi)
[data goes here]

If they needed help, supporters would say "Modify your \nero\app.wpi file to read this instead of that".
---

What I like about VBS is that it was designed as a scripting language for Windows, where Javascript was designed as a scripting language for Web Pages. As such, it's far simpler to look up and apply features in VBS than using JS. I've also noticed a few new features added by other users that are being exploited in VBS than in Javascript, which I attribute to the simplicity to finding VBS scripting info. Mixing 2 languages means that users need to know 2 languages (though neither languages are really that much harder to use than the other...)

Like I said, I'm just dropping a few ideas on the table.

[hasi001]

Now I see what you mean with the distributed config idea. Not that bad. I'm not familiar with WMI. Not even with remote installation as such.
As I see it, your idea would be to 'generate' a config.js from various ini-files. So this generated config-file could be posted by useres for support.
How would this WMI-thing work ?

The problem with WPI -as it's now - is the time, installs take. I'm sure you've seen the various posts with the 'script is taking too long' error. It would be even worse with remote installs (network=bottleneck?). All this, 'cause WPI is waiting till the end of all installs. Any idea in this direction ?

[a06lp]

just my 2 cents: one of the things i like about WPI is that it is a simple folder. my applications folder never has to be modified. i would hate to have to put a "wpi.app" or whatever in each of my app folders...
config.js is waaaaay easier.

[Whimsy]

Hasi001:
Yes, that's a better approach to what I was thinking. The config.js would be generated on the fly based on the available app.wpi files. To handle a06lp's concern, it could check for a pre-existing config file, and if it doesn't see it, it would then create a fresh one on the fly, and then execute it as normal. This would solve the problem of support, since they would, in effect, be the same file.

The advantage to this 2-part setup would be that a CMD file could move directories around, allowing different sets of applications to exist for different CD-Images, or in the context of a network install, its as easy as adding the application and associated .wpi file (perhaps this could be an INI, so users don't have to associate yet another file type. That seems more logical.)

I said WMI, but I was thinking of Active Directory, hence why administrative input would be needed. Basically, RIS provides the Windows setup files, but I think WPI could also be made to handle most of the post install configuration on a per-computer basis. Using Active Directory, computers using WPI could join a domain, or else have temporary accounts generated, and specific, per-machine settings could be applied, but this is probably already handled. Before exploring this, it might be a better idea to get input from administrators, and besides, this would be a far-future milestone, since the scope is immense. I also doubt that most users would have the resources to properly test this.

Heh... I'm arguing with myself

[ICANIT]

Hi Whimsy/hasi

I'm administrating several Windows2003 domains, with AD and RIS. I have used WPI on RIS since version 2.7, its a great "program". but if it in anyway could be possible to launch WPI before the image on my RIS is installed, that would be even more nice.
I am not into programming in VBS or JS, but i would be glad to help, testing on active directory, network, RIS and so on. just let me know.

Keep up the good work :-)