Jump to content

POMAH-PRESS

Member
  • Posts

    24
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Ukraine

Everything posted by POMAH-PRESS

  1. So when is version 3 coming out?.. Gonna be doing some lite'ing soon...
  2. Updated the package today. Changes in changelog.txt.
  3. Sooooo... Have you figured that out or what???
  4. Well, it's like it is written in the guide 1. You don't start run.cmd, in fact there is no run.cmd, not until you start USBMultiWimSetup.cmd. That's what you should be doing. To do that you boot into PE - the boot.wim from your installation media (you must put it on your USB drive as described in the guide). When PE boots and the welcome screen is shown you press Shift+F10 to start cmd window. Then you go to the root of the drive where your wims and xmls are and where your USBMultiWimSetup.cmd should be. If you're not used to cmd interface you can just type notepad there, then in notepad window press Ctrl+O to go to open file dialog - that will present you with an explorer-like window and you will be able to browse your disks just like you would in normal windows. And don't forget to enter "*.*" into filename field to be able to see all the files and not only the .txt ones. So you go to the right directory and right-click the USBMultiWimSetup.cmd and click run as administrator (or whatever, I don't remember atm) so it starts executing and not opens in notepad. And you're done. Or you can avoid all this procedure by integrating files from the archive into your boot.wim like described in the guide - Step 1.a. That way you will see the scripts menu immediately after PE boot. You will just have to Alt+Tab to it. It's all there in the guide, really. I thought I've put all the necessary info there, but I might be wrong... 2. All the files in the sources folder are used only when you start installation from Windows (like upgrading from XP or Vista or 7...). When you start installation booting from DVD (or USB in our case) PE boots and all the same files located inside the PE image are used. That's it. 3. You put your PE wims on the boot disk, USB in your case. You can put them in any folder you like just change the BCD store accordingly. In my guide I use sources folder because it's the standard folder so you don't have to change anything in the BCD. You could put them in, say, "PE" folder and name the wims "pex86.wim" and "pex64.wim" and change the BCD to reflect that. If you don't want to mess with BCD just take the pe wim you need and put it in sources folder, like described in the guide. It's all really simple, you just have to do it right once and you will see that. If the above doesn't answer your questions ask more. We will sort this out, I assure you.
  5. Yeap, that's the way to go I think... 7 and Vista should be deployed separately using this method. I didn't think about Vista when developing this anyway.
  6. That would be great and appreciated. Didn't get that.
  7. Well, I don't see why it shouldn't. I don't have any Vista's to test though.
  8. I've put together techniques from different guides and made a script that allows one to place several WIM's and XML answer files in some directories on one disk (USB, HDD, CD/DVD,...) and have them listed in script's menu after the installation media's PE boot. You can select an image and an answer file to use and start the installation. How it works. PE boots. If you've injected the autostart script into it - disks are scanned and when found USBMultiWIMSetup.cmd is started (if you haven't injected the autostart script you have to manually start the USBMultiWIMSetup.cmd from command prompt). It scans the disk it is on (two dirs, according to path's inside it) for WIM's and XML's. It generates lists/menus including every item it finds. All this is then output to another script which is presented to the end user. This script currently contains 4 pages/dialogs: 1. IMAGES. Here you can see all the images found and must select one to continue. 2. ANSWER FILES. Same here, only here you select an answer file. If you don't have or don't want to use any - select "[0] - none" or skip to another page/dialog. 3. START SETUP. If you're done you can start setup from here. 0. RESTART WIZARD. This is the page where you can restart the script. It doesn't make much sense now, but I have some future plans for extension of this script, that's where it will be used. A simple(st) example: 1. You need some files from an NT6.x installation media: \boot folder with all it's contents \sources folder with a boot.wim file in it, just this one file, nothing else \bootmgr file all this goes to the root of your boot device, whichever you are using. From now on it will be referred to as [boot disk]. 1a. This step is required to have the script loaded automatically on PE boot. You have to inject the StartSetup.cmd and winpeshl.ini files from downloaded archive to boot.wim's second image. The path is: Windows\System32\ 2. You can now put your WIM's and XML's to some folders on some disk. From now on that disk will be referred to as [source disk]. Next thing to do is to edit the USBMultiWIMSetup.cmd and enter the path's to WIM's and XML's you are using at the top of the file. In this example we are using: \IMG for WIM's and \XML for XML's so it looks like this in the .cmd: set wimpth=IMG set xmlpth=XML 3. You need to put the modified USBMultiWIMSetup.cmd file to the root of your [source disk]. Now, the [boot disk] and the [source disk] can be two different devices/disks or it can be one disk. In this example it is one disk. So the next picture shows the end file/folder structure one should get after peforming all the above steps. It also shows what files/folders should go to the [boot disk] / [source disk] if they were two different disks (according to the color). The run.cmd file included in download is the end user generated script for our example. The following pictures show what it looks like. Download:USBMultiWIMSetup v0.9.1 RC.zip Known issues: Current version doesn't allow to use spaces inside commandline's arguments. Example: this works X:\sources\setup.exe /installfrom:H:\IMG\WIM\ENTx64.wim /unattend:%answ_path% and this doesn't work. X:\sources\setup.exe /installfrom:H:\MY IMG\WIM\ENT x64.wim /unattend:%answ_path% Quotes seem to break the command line as well. This needs further testing. My original thread at boot-land.net (reboot.pro)
  9. And those of us that have Win7 installed in drives/partitions other than C:\> are ready to test things when the updates/changes are made. +1
  10. Hey everyone)... Cool down, LOL)... I'm just saying I'll stick to vLite, for now... And then, well... We'll see)... And yes, having Nuhi back here would be really fantastic...
  11. Well, what Nuhi did several years before for Vista fully suits my needs today with my W7... And it is far more stable for me then this tool specifically designed for W7... vLite is a quality product, proven with time.
  12. Hahaha)))... What a nice progie))))... Good luck to you, Dev's... With that kind of attitude and... "quality")))... ChiefZeke: Thnx for clearing this up... P.S. : vLite and DISM rule!) P.P.S. : Nuhi is da BEST!)))
  13. Yes... Why? Is there a difference? Should I use x86 one? I'm on Winx64. Update: Tried x86 version 1.4.0 on W7 x86, same story, but I figured out a way to lunch the app by first pressing "quit" in an error window, and then pressing "Continue" in a second identical window. However, when I'm trying to do something I get the same error repeatedly... So no-go ( ...
  14. 1) If you're talking about the host OS - it's MSDN W7 Pro, where everything is in place. I also tried it on a just installed one, the only modification to it was the WAIK, so it couldn't be messed up. And I never use Windows modified by anybody... 2) If you're talking about the guest, the one that I'm trying to modify - it's irrelevant at all, because I get the error the moment I start the app. 3) If I'm not mistaken, .Net Framework v2.0 - 3.5 is integrated into any W7, so I don't see how that could happen. I also don't understand why it is said to have .Net 3.5 while this app only works on NT6 which comes with it out of the box. Since it's original MSDN W7 image I'm using, it should be there, right? 4) The language question remains. Well, the host OS language is EN. The date, currency... format is set to Russian however, and the location is set to Ukraine. Could that make a difference? Could you please tell me more about the potential language related issues. And what language exactly is in question here? Like host OS UI language or guest language, or what? Cause I'm at lost here...
  15. I'm sorry... But WTF is this? I launch this app on a just installed MSDN W7Pro x64 Eng (WAIK W7 installed too) and all I get is the error. Tried several times, reinstalling host W7... And why do you specify the .Net Framework 3.5 as a pre-requisite for W7 if it's a part of any W7 already?!!! At the same time it looks like some other required files that aren't there by default are not mentioned. Look into this please. So, once again, to clear things up: I just installed my W7 Pro x64, installed WAIK for W7, installed RT Seven Lite. I start it. 1) I get a "WAIK installation" window, suggesting me to DL and install the WAIK, which is already installed. If I press "OK" it's exiting. If I close this window I get 2) the error: See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.NullReferenceException: Object reference not set to an instance of an object. at RTWin7Lite.RT7LiteHome.RT7LiteHome_FormClosing(Object sender, FormClosingEventArgs e) in D:\Ben\4-8-2010\Final_state\RTWin7Lite\RTWin7Lite\RT7LiteHome.vb:line 517 at System.Windows.Forms.Form.WmClose(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900) CodeBase: file:///E:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll ---------------------------------------- RTWin7Lite Assembly Version: 1.3.0.0 Win32 Version: 1.3.0.0 CodeBase: file:///E:/Program%20Files/RT%207%20Lite/RTWin7Lite.exe ---------------------------------------- Microsoft.VisualBasic Assembly Version: 8.0.0.0 Win32 Version: 8.0.50727.4927 (NetFXspW7.050727-4900) CodeBase: file:///E:/Windows/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll ---------------------------------------- System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900) CodeBase: file:///E:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900) CodeBase: file:///E:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900) CodeBase: file:///E:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Runtime.Remoting Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900) CodeBase: file:///E:/Windows/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll ---------------------------------------- RTWin7Lite.resources Assembly Version: 1.3.0.0 Win32 Version: 1.3.0.0 CodeBase: file:///E:/Program%20Files/RT%207%20Lite/en-US/RTWin7Lite.resources.DLL ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box. 3) and after pressing "Continue", the next one: Requiered files are missing. Please reinstall the application. Could anyone tell me how do I pray so this app starts up?
  16. clpdj Hey man... It seems that all Volume (and probably OEM) editions of W7 get messed up when processed by vLite (and probably by any other program alike). At least that's my personal experience with W7 Pro VL and W7 Enterprise VL and vLite. Any Retail version seems to be working out just fine. But I just might be wrong. Correct me someone if I am... Hope that helps...
  17. W7 Pro x64 Lite - YEAH!!!

  18. I'm very very interested (cause vLite is crashing). How do I do that? Will it shrink the image?
  19. That doesn't suit my needs... Can't it remove immediately?
  20. So, what's the purpose of the program once again? Cuz I removed some packages and the size of the image is just the same. So what's the point? W7 Pro x64 here.
  21. Thanks Martin H, will use that! Another issue - been starting unattended (nLited) XPx64SP2 install via WINNT32.EXE from XPx64 environment and I wasn't able to select where to install to (while in textmode). It installed on first volume of sufficient size. I checked those 2: filesystem=* and Autopartition=0. Any ideas? Attaching some files to look at... And how about that $OEM$ issue? How do you add something to be started at T13 with nLite's RunOnce? WINNT.zip
  22. It's an nLited En_XP_Pro_SP3, MSDN... It was nLited once, no SP integration or file editing was done. I've been doing some testing and researching and had figured it out. It works now. What was done: I have rebuilt my image without removing Manual install and upgrade (I only had WINNT.EXE before). Also I realized that I haven't moved the $OEM$ dir to I386\. So I did that. Although during the first copying of files there was one error: couldn't copy some .mui file, the rest of the setup process went flawlessly. Well that error is meaningless as you have to stay near PC until the textmode file copying starts anyway, so for now I ignore that one as long as OS is working fine. The only issue that remains is that my folders containing additional files to install are renamed, that Long File Names issue. So the batch wasn't started and so on... How does one restore the original names or prevent them from being changed? Is that a DOS distro issue (do I need some advanced DOS) or a WINNT.EXE issue (so it will be that way anyway)? That's probably the last issue to resolve here, and I'm ready to start working on x64 edition. I heard there are some major differences. What can you say on the subject? Is the above way gonna work? Will appreciate any info. Thanx in advance. Thanx for reply, pointed me into right direction. Uploaded my session anyway... WOW) That's some nasty file size. XP_MIN_Core_NEW_u.zip
  23. Hi! I'm installing my nLited XP Pro SP3. Works perfect from CD (has been installed many many times)... BUT Now I'm installing it from HDD from DOS command prompt using WINNT.EXE. As I want to install it unattended (as I always did before from CD) I use the same WINNT.SIF file. While in textmode, copying files (at 98%) installation says it can't copy some files. And that would be all the integrated internally by nLite drivers. Well, I skip them all. Then it finishes it's job, reboots and installs as usual (NOTE - WINNT.SIF is working OK). XP installs as usual, but, obviously, non of the integrated drivers are installed. That is one issue I hope you will help with. The other one is that I install some additional stuff using RunOnceEx. I'm starting it from CMD file which in turn is started from cmdlines.txt. The CMD file and that additional stuff are located in the "Unattended" dir which is at CD's root (and is at the same level on HDD as I386 is). Now since the "Unattended" dir isn't copied anywhere by WINNT.EXE nothing is installed from there earthier. So the question is where to place it for WINNT.EXE to find and copy it. And what about the $OEM$ folder (the one that is at CD's root and on the same level as I386) - is it processed/copied by WINNT.EXE? NOTE that this method involves source files copying TWICE: First, files from source folder are copied somewhere to TEMP destination immediately after starting WINNT.EXE. That seems to be the point where my additional folders and NLDRV dir are not copied. Then, after reboot, in the OS Selection screen there is a new item called smth like Upgrade/Installation. That's our XP installation in fact. So I hit it, and the usual installation starts, as if started from CD. Now files are copied again to the destination drive. That's where it says it can't find integrated drivers. Then install goes as usual. Also, system tries to log me in as "Administrator" and fails, as there is no such user account. Any ideas about why it doesn't log me in to my created account? Please don't bother with questions like: "Why not install from CD?" I have my reasons and want to install from HDD.
×
×
  • Create New...