Jump to content

allanf

Member
 View Profile  See their activity

  • Posts

    66

  • Joined

  • Last visited

  • Donations

    0.00 USD 

  • Country

    Australia

 Content Type 

Everything posted by allanf

  1. allanf
    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. allanf
    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. allanf
    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. allanf
    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. allanf
    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. allanf
    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. allanf
    Good idea! However, the aim is not clear enough... "With support of scripts". What do you mean? Regards
  8. allanf
    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. allanf
    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. allanf
    @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. allanf
    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. allanf
    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. allanf
    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. allanf
    IMHO... WinPE or BartPE for sure! ... ... Forget about Winbuilder! ... ... Hi Nuno ... ...
  15. allanf
    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...)
  16. allanf
    Icecube has kindly provided a new ISOLINUX (SYSLINUX 3.83) module for CD SHELL. Better late than never...
  17. allanf
    DISKPART> list partition Partition ### Type Size Offset ------------- ---------------- ------- ------- Partition 1 OEM 196 MB 31 KB Partition 2 Primary 750 MB 197 MB Partition 3 Primary 231 GB 947 MB Thanks. How about "list volume" to show how the drive letters are assigned? And "select disk 1", "list partition", "list volume" for the UFD? That is - as soon as you manage to stop the sky from falling.
  18. allanf
    Thx. I'm interested to see how it looks.
  19. allanf
    I am not sure to get it. The only thing I cannot see is a drive "d:" Must be referring to "d:" as seen by WinPE 3.0 ... ... Having the UFD poses another question. Is it seen as a removeable drive in WinPE? From a clean install of Win7, the system partition (containing Win7 boot files, bitlocker stuff, etc) is hidden and active, but it is seen by WinPE. Here, an OEM partition is hidden but may still be seen by WinPE. So the "default order" might be: E: (active system partition) becomes c: in WinPE F: (removable) becomes d: ... not sure about this one! No letter (OEM partition, assuming it is the first non-active primary and is seen by WinPE) becomes e: C: (boot partition with OS files, assuming it is a later primary) becomes f: @cyberwatchers. Still a few questions. In WinPE, can you do a "diskpart: select disk 0, list vol, list part"? Right click cmd-window title bar, mark and copy the cmd-line output. Exit diskpart, start notepad and paste the output into notepad txt file and save the .txt to a known partition? Then post the text here? If you have time that is.
  20. allanf
    Is that a typo? Should be "wpeutil DisableFirewall".
  21. allanf
    That seems right for Windows PE 2.1. Thanks. Here's a laptop HDD - repartitioned after it was severely damaged when my wife inserted a CD into the optical drive.Disk Management (Win7 RC1): diskpart (WinPE 2.1): First the active primary (c:), then the logicals (d: and e:), then the remaining primaries (f: and g:). Awaiting what cyberwatchers has to offer....
  22. allanf
    You make it sound too easy ... ... And, quite right, it's not a FOR /F loop, just a plain FOR loop. I was thinking of another batch I've been working on ... ...
  23. allanf
    Just guessing that the @ScriptDir macro is similar to a VB Script I've seen for finding its own path and drive.... The standard method of booting Windows PE is to load it into RAM which is assigned the drive letter x: (although the letter can now be changed using DISM when customising Windows PE 3.0). The script (VB or batch) or autoit program would normally execute from the RAM drive, so the script (or program) itself shouldn't be too hard to find. Use the %SYSTEMDRIVE% environment variable. The images will reside on the DVD, which would still need to be found. The FOR /F loop batch is the simplest method I have seen. I guess there is the option of running Windows PE from the DVD, rather than RAM, in which case, the script and the images would be on the same drive. (... not sure how the drive letter is assigned in this case?) Or, if the images are small enough, load them into RAM as well, where they can be easily found.
  24. allanf
    Windows PE (rather than RE) is probably a better environment for deploying from a CD/DVD. Just the other day, I rebooted and what d'ya know - Windows RE thinks there's a serious problem, does unspecified exhaustive scans and tests, then admits that it can't fix the problem. Fortunately, on reboot, everything seemed OK. That's as much as I know about RE. Create a uniquely-named tag file on the CD/DVD. When Windows PE boots, run a FOR /F loop in batch script to search drives for the tag file and assign the correct drive letter to a variable. There are a few variants of the FOR /F loop. Good luck.
  25. allanf
    Yeah. I did see that one. However, I assumed that the Dell Recovery Partition was not the active partition, and that there was an active partition somewhere. The first scan: Based on my assumptions, the Recovery Partition should not be assigned c: The MS-DOS/9x/ME "default order" did seem to fit the bill, but I was trying, in a subtle way, to indicate that I have no idea. I'll pay more attention to the matter when next I boot Windows PE.
×
×
  • Create New...