Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×


  • Content Count

  • Joined

  • Last visited

  • Donations


Community Reputation

0 Neutral

About allanf

Contact Methods

  • Website URL
  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 '***
  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. (
  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,
  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
  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. W
  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 whee
  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
  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
  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 gu
  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
  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
  • Create New...