allanf

Member
  • Content count

    66
  • Joined

  • Last visited

Community Reputation

0 Neutral

About allanf

Contact Methods

  • Website URL
    http://
  1. The problem with HTAs is that they become unresponsive when performing certain tasks. An HTA can open a reliable Modeless Dialogue Window to show activity. See how the script and style for the Modeless Dialogue Window can be written on-the-fly by the HTA, such that there is no need for more than one file - the main HTA. objProgressWindow.document.write ProgressHTML.innerHTML where "ProgressHTML" is enclosed in XML tags within the body of the HTA. <html> <head> <meta http-equiv="x-ua-compatible" content="ie=9"> <script type="text/vbscript"> HTAResize '********************************************************************************' '*Before HTA starts, resize screen. *' '********************************************************************************' Sub HTAResize window.resizeTo 800,640 intHorizontal = Document.ParentWindow.Screen.AvailWidth intVertical = Document.ParentWindow.Screen.AvailHeight intLeft = (intHorizontal - 800) / 2 intTop = (intVertical - 640) / 2 'move to centerscreen window.moveTo intLeft, intTop End Sub </script> <hta:application id="htaHTA" applicationname="WinRE-O-Matic" border="dialog" maximizebutton="no" minimizebutton="no" scroll="auto" </hta:application> <script type="text/vbscript"> Sub window_onLoad window.setTimeout "OpenProgressWindow", 0, "VBScript" End Sub '********************************************************************************' '*Progress bar. *' '********************************************************************************' Dim objProgressWindow Sub OpenProgressWindow intProgBarWidth = CInt(document.documentElement.clientWidth) intProgBarHeight = 18 intLeft = window.screenLeft intTop = window.screenTop + document.documentElement.clientHeight _ - intProgBarHeight strOptions = "dialogWidth:" & intProgBarWidth _ & "px; dialogHeight:" & intProgBarHeight & "px; dialogLeft: " _ & intLeft & "; dialogTop: " & intTop & "; unadorned: yes; scroll: no;" Set objProgressWindow = _ window.showModelessDialog("about:blank", self, strOptions) objProgressWindow.document.write ProgressHTML.innerHTML strTimedIterations = "TimedIterations" _ & "(" & Chr(34) & intProgBarWidth & Chr(34) & ")" objProgressWindow.setTimeout strTimedIterations, 10, "VBScript" End Sub Sub CloseProgressWindow objProgressWindow.close End Sub </script> </head> <body> <xml id="ProgressHTML"> <html> <head> <script language="vbscript"> intCounter = 0 window.returnValue = self Sub TimedIterations(fullWidth) intFullWidth = CInt(fullWidth) intBarBlockWidth = 150 If intCounter < intBarBlockWidth Then spnBar1.style.width = intCounter Else spnBar2.style.width = intCounter - intBarBlockWidth If intCounter > intFullWidth Then spnBar1.style.width = intBarBlockWidth - (intCounter - intFullWidth) If intCounter = intFullWidth + intBarBlockWidth Then spnBar2.style.width = 0 intCounter = 0 End If End If End If intCounter = intCounter + 1 strTimedIterations = "TimedIterations" _ & "(" & Chr(34) & intFullWidth & Chr(34) & ")" window.setTimeout strTimedIterations, 1, "VBScript" End Sub </script> </head> <body style="background-color: #FFC106; cursor: wait; border: none;"> <span id="spnBar2" style="background-color: #FFC106;"> </span> <span id="spnBar1" style="background-color: green;"> </span> </body> </html> </xml> </body> </html> BTW, as a demonstration, there is nothing in this code to cause the Modeless Dialogue Window (the Indeterminate Progress Bar) to close.
  2. That's disappointing news, nishants52. When do you think you might be available to take on this project? @Kullenen_Ask It might be useful to list your current step-by-step procedure for creating your customized WinPE. NOT how you compile your data and settings (registry keys and file lists) - rather, how you incorporate them into a standard winpe WIM. That way, a programmer might have a better idea of what the program should actually do. A member, martinr, has kindly made available the source code (c++) for his WIMMaster program, which would be a start for any program dealing with WIM files. (Note that wimgapi.dll is now available in all Windows 7 installations.) Post: Download: http://martin.boot-land.net/WIMMaster/ Another alternative, which jaclaz may have hinted at (and which flew over my head), might be to use an installer program like NSIS or INNO Setup. Here you would need to learn another scripting language to compile an installer (.exe or .msi) which when executed would present the user with a GUI of options and components that can be added to a customized WinPE. Rather than installing to the current online OS, the installer would firstly need to mount a WIM image, then install to that offline mounted WIM. Regards
  3. My idea also little wheels preferably. One big giant wheel will make fault locating very difficult. Will make it dependent for the inventor. On person should do all. But little wheels more customizable and easy for different people to make small plugins. Each plugin is one handcrafted spoke in the wheel. The program assembles the spokes. More than that, the big wheel could optimize the build process. Say plugin1 wants x.dll, and plugin2 wants the same. Why run each little wheel, duplicating file-copying. Same with registry settings. You can easily identify conflicts if everything is compiled, and why repeatedly load and inload hives?
  4. Don't want to seem too "captain obvious", but till now you have described the interface of *any* installer, including that of .msi files or common NSIS ones. In this respect NSIS could be a very good "scripting engine". Do try to keep up with the progress of the thread, jaclaz. I specifically sought clarification of the term "scripting". Subsequently, the notion of a "scripting engine" was removed from the agenda (for the time being). We're now talking about "plugins" which is a very familiar theme. winbuilder runs each of it's scripts as individual processes - like a bunch of little wheels rolling one-by-one. I don't know about PEBuilder. My idea is for the program to assemble all the spokes into one giant wheel THEN start rolling.
  5. OK. That's clearer. The term "plugin" might be more appropriate. But it's still not for any old noob to come along, write out a few scripts/plugins and have customized versions MediaPlayer, IE9, MMC, explorer and .NET up and running in a PE in half an hour. Some ideas... The proposed program has a set of directories and a prescribed format for the plugin files. The files are placed in the directories. When the program starts, it enumerates all the valid plugins in the directories and presents the user with a checklist. When an item is checked, its dependencies are automatically checked also. When the "Build" button is pressed, the program parses the plugin files into one big .reg file and one big file-copy list. Then it mounts a wim image (rw), loads the registry hives, runs the big .reg file, copies the files in the big file-copy list, unmounts (commits) the wim image and makes an .iso for CD and/or "flat" structure for UFD. There are scores of other options that could be considered - relating to the PE generally and to the plugins specifically. Where do they all fit in? Each item in the checklist could have it's own configuration window - say a pop-up dialog of radio-buttons, textboxes, etc that would adjust the standard plugin variables. KAPE looks to have solid mechanics for handling wim files. It's not a bad template in that regard. It's lacking the plugin capability though. PEBuilder's plugin method plus winbuilder's configuration interfaces could provide inspiration and ideas. It all might seem very familiar, but I think if it is well thought-out, it could be a major improvement on what's already out there.
  6. Thanks for the quick reply. But please think about your aim. You want someone to develop a whole new scripting language? That anyone can use? As you know, building a custom PE can be boiled down to just a few fairly basic functions. These things could be presented to a user as a simple scripting language. Another approach might be for you (yes, you ... ...) to maintain a backend database of all the popular programs and their settings, and a new user is only ever exposed to a GUI for basic customization, and forget about user-scripting altogether. That way, you could end up with a rounder wheel. Regards
  7. Good idea! However, the aim is not clear enough... "With support of scripts". What do you mean? Regards
  8. Mexxi, Have you tried the new feature of WinPE 3.0 called profiling. I haven't, but apparently you can turn it on with DISM in a basic winpe, run the winpe and use only what you want, then rebuild the winpe using the created profile, and everything should be stripped out except what you need... apparently... Maybe worth a try. Regards
  9. Probably a long-shot... but might be interesting to do a Dependency Walker profile of some other wireless networking manager - like one specific to the adaptor. For example, Intel® PROSet/Wireless WiFi Connection Utility for Windows 7 32-Bit*. There's a zip file there which may be installable to the off-line winpe. Alternatively, the program may be installable online in a running winpe and the installer would probable say what's missing and required. To start, add all the packages in the WAIK and the wireless driver, and throw the installer and depends.exe into /system32..., and have plenty of RAM. ... just a thought. Regards
  10. @Sulfurious A "flat file" is what you don't need - it is the set of OS files applied directly to the media with no container like a wim or vhd, and consequently, when booted, it runs from the booting medium and must stay connected to its medium (hdd, cd, usb). Using a wim or vhd, the OS is loaded entirely into RAM. Once booted, the booting medium can be dispensed with - the cd can be ejected, the usb can be unplugged, or the hdd can be wiped clean. When booting from an iso (on cd, or with grub4dos or memdisk/syslinux on other media) make sure the required tools and files are packed in the wim or vhd so that they are also loaded into RAM - otherwise, they will require the presence of the booting medium. Here is a method for creating the basic winpe 3.0 vhd to boot from hdd using Windows Boot Manager (BCD). @wimb I must say that it's very nice to see you working on a winpe 3.0 project to host your tools. Regards
  11. But, if you really want to stick with Windows AIK for Vista SP1 - which IMO was the best thing to come out of the Vista era - use peimg. For example: peimg /inf=c:\mydevice.inf c:\winpe_x86\mount\windows http://technet.microsoft.com/en-us/library...161(WS.10).aspx When changing WAIK versions, it is recommended to uninstall an existing version using Control Panels. Regards
  12. HeHe! I thought everyone was using it. I misread Br4tt3's VBScript and don't quite understand dabone's "parseFile" Sub. Makes me wonder now if the stdout from the earlier imagex's "/xml /info" switches was ever readable/parseable by the DOM. My hta was originally scripted with Win 7 Tools installed, but I dropped the project. At some stage, I switched back to WAIK for Vista SP1, then recently tried to restart the hta project but couldn't figure out what was wrong. Misreading Br4tt3's VBScript from Aug 2008 also made me think that others had had things working with the earlier imagex. Now, I guess I'll never know. The hta parses the entire stdout (without redirect/print to file) from imagex /xml /info into readable html for the hta's display. I use it for selecting and customizing WinPEs. Regards
  13. Tripredacus Thanks for your reply. The issue I am having may not be apparent when the stdout is redirected to file. However, the hta I am using reads directly from the stdout. Apart from the node re-ordering, there seems to be some significant change in the rendering of the well-formed XML. On each system, I have installed and re-installed the various Windows AIK versions, taking care to properly uninstall an existing version before installing a new. To illustrate the differences between the rendering of the XML, here are two screenshots - one of XP SP3 with WAIK 1.1 (for Vista SP1 and Server 2008), and one of Windows 7 RC1 with WAIK 2.0 (for Windows 7). It does not matter which system is used - XP or Win7. The results are the same for each of the two versions of imagex on either system. imagex_1.1_XPsp3 imagex_2.0_W7rc1 Notice for imagex from WAIK 1.1 the leading symbol that I mentioned in my earlier post. There is also the rather obvious spacing between each letter in the stdout. What is going on here? Thanks
  14. IMHO... WinPE or BartPE for sure! ... ... Forget about Winbuilder! ... ... Hi Nuno ... ...
  15. Time has passed, but I think something may have changed. I have dug up an old HTA that was working as expected - similar to the above script - but can't figure out what has broke. The only Echo I get from the "stdout.readall" from "imagex /xml /info" is: ÿ_< This presumably is the first symbol and first bracket in the "well-formed XML" seen by running the imagex command straight on the command line: ■< W I M > < T O T A L B Y T E S > 1 8 2 7 4 3 7 5 7 < / T O T A L B Y T E S > < I M A G E I N D E X = " 1 " > < N A M E > M i c r o s o f t W i n d o w s V i s t a P E ( x 8 6 ) < / N A M E > < D E S C R I P T I O N > M i c r o s o f t W i n d o w s V i s t a P E ( x 8 6 ) < / D E S C R I P T I O N > < W I N D O W S > etc, etc To test the cmd-line output and the "stdout.readall" Echo, I have used the following adaptation of Br4tt3's vbscript executed with cscript from the cmd-line. A separate cmd-window opens from "WshShell.Run" to show the normal XML output, and the "WScript.Echo ExecAppRM(strArgument)" Echos the strange stdout.readall in the main cmd-window. Option Explicit Dim strWIMFile Dim strArgument Dim strArgumentRun strWIMFile = "C:\Program Files\Windows AIK\Tools\PETools\x86\winpe.wim" strArgument = Chr(34) & "C:\Program Files\Windows AIK\Tools\x86\imagex.exe" & _ Chr(34) & " /XML /info " & Chr(34) & strWIMFile & Chr(34) strArgumentRun = Chr(40) & strArgument & Chr(41) WScript.Echo ExecAppRM(strArgument) Function ExecAppRM(pstrCommand) Dim oRun Dim n Dim WshShell Dim strResult Set WshShell = WScript.CreateObject("WScript.Shell") n=0 WshShell.Run "cmd /k "+strArgumentRun, , True Set oRun=WshShell.Exec(pstrCommand) ExecAppRM = oRun.StdOut.ReadAll End Function Could anyone explain what's going wrong? I'm sure it used to work. Tested on XP SP3 and Win7 RC1. Thanks Edit: Cleaned up vbscript - used "strArgument" in "strArgumentRun = " Edit: Hmmm... Not to worry. I found that changing to the version of imagex from WAIK for Win7 solves the problem (but does not solve the mystery of why an older version of imagex used to work then suddenly didn't...)