Jump to content

whitehorses

Member
  • Posts

    87
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Hungary

Everything posted by whitehorses

  1. I see. I'm looking forward to hear your opinion of it. Happy new year by the way. This was the third isn't it?
  2. @TC I'm sorry to bump this post, but i have just tried HFSLIP 1.7.1, and it still has the same problem. Have you looked at the changes I made to 1.7.0, because that way the issue is solved for sure... without using HFSLIPGUI for the deletion INF folder.
  3. TommyP. I have made some changes please look at it. Search for "WHITEHORSES MOD HERE" to find them. It is working surprisingly well, but this does not mean that there could be no complications when using W2K directx for example, (simple RunOnce entries might need run after RunOnceEx... I dunno) But this works for me with a HEAVILY nLighted and HFCLEANUPed (wmp6&9) source, whithout a single error. (see logs) hfslip_170mod.zip logs.zip
  4. TommyP Thanks for your reply. My problem is, as you see is that I think I give and have given really great effort into understanding this f*ckin sh*t installations process, but it's out of my power to catch up with that understanding of yours. I was pharsing the HFSLIP source code for a year in the past every day, yet I was unable to find such things out by myself. I really hate nlite for example because they are just another "black box" like Windows. You put in something, you get something, but you don't know the reasons, the methods applied. HFSLIP is better in the sense that the code is there, and one might be able understand it by himself. I HFSLIP everything into it, put it on the shelf, then I make slimmed down version according to the current needs. At least nLite can handle it, or seems so... (blackbox effect?) ------- EDIT: I wrote that line, because I added that to the end of HFSLIPWU.INF, while also killed HFSLPGUI.INF. And there was no error, that is the HFSLIP folder was deleted as it had to. I checked the code. If I'm right RunOnce executes before RunOnceEx. If that is the case then it seems like the only thing which could go wrong with this method is that DirectX uses ZZZ entries, which are to be processed after. (If I'm right no other entries reference to HFSLIP folder by that time). If we change Directx to ZZX (X for convinience ) and put this line to the end of HFSLIPWU.INF, everything ought to be fine... HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\ZZZ","999",0,"CMD.EXE /C RD/Q/S ""%SystemRoot%\HFSLIP""" edited: corrected te above line, seems like ok now. Also I think I found something wrong in hfslip 1.7.0 Final ...HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\ZZZxpsp1",999,bitsupdate,"cmd.exe /c ""%%SystemRoot%%\SYSTEM32\BITSINST.EXE /setbackupfilter""" That "bitsupdate" should be 0x00000000 or 0 or nothing at all. I'm not sure.
  5. Yawn... By the way i made a test run with the current test release and the problem was still there, ie. that HFSLIP folder gets deleted before RunOnceEx entries of HFSLIPWU.INF get their turn. It seems to happen only if nLited after hfslipping for some reason. I have searched for some RunOnceEx info, and after what I found I don't realy understand the method here. RunOnceEx supposed to execute its entries in order, so I don't see why not to use it. HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\ZZA","999",0,"CMD.EXE /C RD/Q/S %10%\HFSLIP" EDIT: After a few hours of deciphering text, it turns out that I was wrong, because by just adding that it does not assure anything that other RunOnce entries (directx?) will be able to run. I think it can not be easily solved for now, because hfslip uses all kind of methods to run the inf files (for example HFSLPDY). Why not using only RunOnceEx, it would be any easy way to solve this... I have to sleep I think...
  6. Here is a list of files which nLite removed, and were in the generated NEWBIN.TXT too archvapp.inf authroot.sst axaltocm.dll basecsp.dll bcsprsrc.dll cobramsg.dll delroots.sst drmupgds.exe guitrna.dll ifxcardm.dll MFPLAT.dll migisma.dll migwiz.htm migwiz.man migwiz2.htm migwiza.exe pintool.exe roots.sst scripta.dll spmsg.dll sysmoda.dll updroots.exe updroots.sst uWDF.exe verclsid.exe WdfApi.dll WdfMgr.exe wmdrmdev.dll wmdrmnet.dll wmdrmsdk.dll wmvadvd.dll WMVADVE.DLL wpd_ci.dll wpdconns.dll wpdmtp.dll wpdmtp.inf wpdmtpdr.dll wpdmtpus.dll WPDSp.dll wpdtrace.dll wpdusb.sys xpsp3res.dll Also these files are ALL what HFSLIP added except the HFS*.INFs, so everything was removed. I mean it is possibly not an error, if these are only what I asked nlite to do. TommyP, can you see anything in this list that must not be removed in any case at nLite removal? (esential system component or something) If not, then I think everything is ok, since the install was smooth, there was not a single entry in errorlog too, so...
  7. As I remember nLite never touches HF*.INF files, so if the added files are not removed from SOURCESS, then there should be no problem. HFSLIP should work separately, but still somehow they seem to interact. The problem is that nLite is closed source, and no one knows if nuhi is making an A-bomb behind the scenes EDIT: ----------------------------- I was using HFSLIP v1.7.0 Final, when the problem occured. I changed HFSLPGUI.INF like this: HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx",ZZZ,0x20000,"CMD.EXE /C RD/Q/S %WINDIR%\HFSLIP" Well actually after the install I found the HFSLIP dir so it wasnt working but I tried at least End it's still better than deleting it before running. So to say, I will check the latest test release then. As I said I also wanted to remove WMP(9&6), while slipstreaming WMF9 codecs. I did the following: 1.) I created a removal set for HFCLEANUP, which is very safe, at least it does everything the originals, plus adheres to the "nLite keepbox list" at tommyp's HFCODECS guide. 2.) After this I used nLite with Sound Drivers and Windows Media Player 6 DESELECTED, so not to mess up anything. The RESULTS are: -------------------------------- So far it works like a charm. I use MPC and it plays .wmv and .wma files fine. No errors suring install, setuperr.log is 0Kb, so I'm statisfied with this. Everithing installed fine. Here is a screenshot: I have some QUESTIONS though: ---------------------------------------- 1.) I made the HFCLEANUP removal files, so that they keep wmnetmgr.dll and sl_anet.acm among others, because they were in the "keepbox" stuff. Are they needed? (most of these files I am talking about are in MultiMed_WindowsMediaPlayer9a.rem that is) 2.) In the TOTAL remover I used the ZZZZZ original, and put in msoobci.dll and wmsetsdk.exe plus made a filter for HFSLIPWU.INF not to create folder in Program Files. I dont really found anything about these files... what are they for? Streaming I think not at least... whs_logs.zip
  8. Hello Tomcat Hi LeveL I have EXACTLY the same problem. I have gone throught those five steps exactly the same way, and had errors hfslp200.inf to hfslp287.inf (i think MS made some hotfixes during the time ) It is interesting, because I have HFSLIP15*.inf-s also, those seem to install fine. I have used the latest final 1.7.0. ... I see that the RD %SYSROOT%\HFSLIP command has moved to HFSLPGUI since then. Now the problem still comes up after first gui logon WHY?!? Uh..what if the HFSLPGUI RunOnce would be changed to RunOnceEx ZZC ? By the way I'm just making a test install with pure HFSLIP (without nLite) so I will come back with the results. EDIT: Back with the results, and good news: it installed fine, so primarily it's not a problem with hfslip. @Tomcat Do you have any ideas what nLite messes up? where can it interact with HFSLIP files for such results? Is it possible to do this without modifying HFSLIP files, because I can check easily if that's the case?
  9. i've just did a reinstall, then searched the install drive for for files listed in my HFSLP151.INF's some files were missing, like mp43dmod.dll, but i don't think that was the case. all the others were in system32. I don't think because I have issues with wmv and wma playback, and those dll, were there in sys32. What I'm concerned of is how do the filters got registered after they are copied over... um... if I'm right, maybe from txtsetup, or hfslipwu...? I think the problem could be there, and I will check it rightaway, by making an inf manually with only the wmpocx.reginst. What do you think? EDIT: wrong, I was. hfslipwu seems to register them. Unfortuantely I don't have the time to reinvent the wheel at the momment, so i give this up now. I just say it has never worked for me even in the past, so I'm quite surprised I'm the only one with this issue.
  10. How would that affect? What should I look for?
  11. Are you sure? I thought for sure that was the problem Hmm... I would do the following: Reinstall, then check which entries are missing from the ones in WMFSDK.INF. Do you think that's enough?
  12. Here is HFSLIPWU.INF Well nope, it's not so fast, PM 1400Mhz I think. With compression C I did so, and the ISO is 354Mb. Not using NLite, just what has been already written. This time I was even using an unmodified HFSLIP version 1.6.3, so... EDIT: GOTTCHA!!! I think I found it... in the begining of HFSLP151 the original [Version] tag is not removed, and interupts the DefaultInstall section. Am I wrong? [Version] Signature="$WINDOWS NT$" [DefaultInstall] AddReg=AddReg.CDRW,reg.devices,Reg.Codecs,V9Reg.Core,V9Reg.Core.AddOnly,V9Reg.Univ,V9.RegPUI, WMPAddReg.PUI,WMPAddReg.OSPUI,WMP.ARP RunPostSetupCommands=RunPost [Version] Signature="$Chicago$" AdvancedINF=2.5, "You need a newer version of Advpack.dll." RequiredEngine=setupapi UnRegisterOCXs=WM8.UnReg CopyFiles =WMPCopy.System, WMCopy.WinDir, CopyINF, WMPCopy.System.Downlevel DelFiles=Del.OldCodecs DelReg=DelReg.Uninst ... I've sent the HFSLP151.INF too. EDIT2: I was silly sorry. I see that only addreg runs from defaultinstall, because the files are copied from by other infs. HFSLIPWU.zip HFSLP151.zip
  13. Hi everyone! I just have a question. I use Media Player Classic (CCCP), nothing else, so I could not check if the issue is only with it, or with WMP too, but for some reason wmfdist.exe does not integrate into my source as it should, since I can't play .wma and .wmv files after installing windows and then MPC. No errors, nothing seems wrong, it just simply won't play. More to that, if I run wmfdist.exe manually it installs smoothly, all shines, and it works. It is not an issue with the current releasefor sure, since I had this problem in the old times back then, but since it was easy to solve by just doing it manually, I have not complained. For sure it's me doing something wrong, because this is a basic procedure, and no one has ever reported any issues about it. Any ideas? PS: Uhmm... this might be asked for, if I'm correct This file is automatically generated by HFSLIP HFSLIP is for personal use only Copyright(C) TommyP 2005-2007 ============================HOW TO REPORT A PROBLEM============================ If running into problems, refer to http://hfslip.org/support.html HFSLIP support forum: http://msfn.org/board/index.php?showforum=129 =============================================================================== HFSLIP Version - 1.6.3 build 71001 HFSLIP Path - D:\OSFORGE\SLIPSTREAM\ OS in SOURCESS - 2000 SP4 English MSIE Version - FDV FDV Fileset - Used DirectX Slipstreamed Drivers - DRIVER.CAB Updated CD Install Path - Default CDTAG - CDROM_NT.5 =============================================================================== Files in your FIX folder: NTDETECT.COM NTLDR Files in your HF folder: gdiplus_dnld.exe IE5.01sp4-KB938127-Windows2000sp4-x86-ENU.exe IE5.01sp4-KB939653-Windows2000sp4-x86-ENU.exe MDAC_TYP.exe MDAC281-KB927779-x86-ENU.exe OE5.5sp2-KB941202-Windows2000-x86-ENU.exe rootsupd_fe44934fd80dd11fec2f0f9b24431658a4f6d589.exe Windows2000-KB842773-x86-ENU.exe Windows2000-KB891861-v2-x86-ENU.exe Windows2000-KB893756-x86-ENU.exe Windows2000-KB896358-x86-ENU.exe Windows2000-KB896423-x86-ENU.exe Windows2000-KB899587-x86-ENU.exe Windows2000-KB899589-x86-ENU.exe Windows2000-KB900725-x86-ENU.exe Windows2000-KB901017-x86-ENU.exe Windows2000-KB901214-x86-ENU.exe Windows2000-KB904706-DX9-x86-ENU.exe Windows2000-KB905414-x86-ENU.exe Windows2000-KB905749-x86-ENU.exe Windows2000-KB908506-x86-ENU.exe Windows2000-KB908519-x86-ENU.exe Windows2000-KB908531-v2-x86-ENU.exe Windows2000-KB911280-v2-x86-ENU.exe Windows2000-KB913580-x86-ENU.exe Windows2000-KB914388-x86-ENU.exe Windows2000-KB914389-x86-ENU.exe Windows2000-KB917008-x86-ENU.exe Windows2000-KB917344-x86-ENU.exe Windows2000-KB917537-x86-ENU.exe Windows2000-KB917953-x86-ENU.exe Windows2000-KB918118-x86-ENU.exe Windows2000-KB920213-x86-ENU.exe Windows2000-KB920670-x86-ENU.exe Windows2000-KB920683-x86-ENU.exe Windows2000-KB920685-x86-ENU.exe Windows2000-KB921398-x86-ENU.exe Windows2000-KB921503-x86-ENU.exe Windows2000-KB922582-x86-ENU.exe Windows2000-KB923191-x86-ENU.exe Windows2000-KB923414-x86-ENU.exe Windows2000-KB923689-x86-ENU.exe Windows2000-KB923810-x86-ENU.exe Windows2000-KB923980-x86-ENU.exe Windows2000-KB924270-x86-ENU.exe Windows2000-KB924667-x86-ENU.exe Windows2000-KB925902-x86-ENU.exe Windows2000-KB926121-x86-ENU.exe Windows2000-KB926122-x86-ENU.exe Windows2000-KB926247-x86-ENU.exe Windows2000-KB926436-x86-ENU.exe Windows2000-KB927891-x86-ENU.exe Windows2000-KB928843-x86-ENU.exe Windows2000-KB930178-x86-ENU.exe Windows2000-KB931784-x86-ENU.exe Windows2000-KB933729-x86-ENU.exe Windows2000-KB935839-x86-ENU.exe Windows2000-KB935840-x86-ENU.exe Windows2000-KB935843-x86-ENU.exe Windows2000-KB936021-x86-ENU.exe Windows2000-KB938827-x86-ENU.exe Windows2000-KB938829-x86-ENU.exe WindowsInstaller-KB893803-v2-x86.exe WindowsMedia6-KB925398-v2-x86-ENU.exe WindowsMedia-KB911564-x86-ENU.exe wmfdist.exe wmp6cdcs.exe Files in your HFCABS folder: BDANT.cab dxnt.cab Files in your HFSVCPACK folder: Files in your HFSVCPACK_SW1 folder: Files in your HFSVCPACK_SW2 folder: Files in your HFGUIRUNONCE folder: Files in your HFTOOLS folder: 7za.exe boot.bin cdimage.exe HFANSWER.INI reg.exe =============================================================================== HFSLIP run time: 12m41s
  14. Hi! I just tought you might have the problem like I did, namely that MDAC_TYP.exe is not the SP1 version. It has to be exactly 6100504 bytes. If it's not then it isn't 2.81. I had accidentaly grabbed version 2.8 and I it gave me the same bidinrtx.inf error. There is a checksum at Tomcat's list too. You might want to check it.
  15. Oleg This is not about an issue at all. Of course it works for you. By default fdv's txtsetup.sif puts appwiz.cpl into systemroot (i.e. WINDOWS folder) not in system32, to prevent its icon appear in control panel. This way you can use it since systemroot is in the path variable
  16. Here is what have been doing: - Found a better solution than renaming appwiz.cpl (no hacking was needed anyway, just removing the registering entry from syssetup.inf was enough even then) so that I drop this too IE.INF addreg to prevent appwiz.CPL from loading: ; ; Added entry to prevent loading the obsolete appwiz.cpl ; HKCU,"Control Panel\don't load","appwiz.cpl",,"No" HKU,".DEFAULT\Control Panel\don't load","appwiz.cpl",,"No" Both shell32 and shdocvw register appwiz.cpl as .lnk handler, I didn't want to fight with "them" over that key - Testing of the following keys is the next (added these to IE.INF delreg): ; ; ShellFolder keys from SHDOCVW.DLL (TESTING) ; HKCR,"CLSID\{00020D75-0000-0000-C000-000000000046}" ; uhh dunno, just suspicious HKLM,"SOFTWARE\Classes\CLSID\{00020D75-0000-0000-C000-000000000046}" HKCR,"CLSID\{A5E46E3A-8849-11D1-9D8C-00C04FC99D61}" ; CLSID_CBaseBrowser HKLM,"SOFTWARE\Classes\CLSID\{A5E46E3A-8849-11D1-9D8C-00C04FC99D61}" ; CLSID_CBaseBrowser HKCR,"CLSID\{E7E4BC40-E76A-11CE-A9BB-00AA004AE837}" ; CLSID_CDocObjectFolder HKLM,"SOFTWARE\Classes\CLSID\{E7E4BC40-E76A-11CE-A9BB-00AA004AE837}" ; CLSID_CDocObjectFolder HKLM,"Microsoft\Windows\CurrentVersion\Shell Extensions\Approved","{E7E4BC40-E76A-11CE-A9BB-00AA004AE837}" ; CLSID_CDocObjectFolder ; ; Class keys in BROWSEUI.DLL (TESTING) ; HKCR,"CLSID\{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}" HKLM,"SOFTWARE\Classes\CLSID\{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}" ; Microsoft Internet Toolbar HKCR,"CLSID\{7376D660-C583-11d0-A3A5-00C04FD706EC}" HKLM,"SOFTWARE\Classes\CLSID\{7376D660-C583-11d0-A3A5-00C04FD706EC}" ; Trident Image Extractor HKCR,"CLSID\{603D3800-BD81-11d0-A3A5-00C04FD706EC}" HKLM,"SOFTWARE\Classes\CLSID\{603D3800-BD81-11d0-A3A5-00C04FD706EC}" ; Background Task Scheduler (TESTING) HKCR,"CLSID\{603D3801-BD81-11d0-A3A5-00C04FD706EC}" HKLM,"SOFTWARE\Classes\CLSID\{603D3801-BD81-11d0-A3A5-00C04FD706EC}" ; Shared Task Scheduler (TESTING) HKCR,"CLSID\{DD313E04-FEFF-11d1-8ECD-0000F87A470C}" HKLM,"SOFTWARE\Classes\CLSID\{DD313E04-FEFF-11d1-8ECD-0000F87A470C}" ; User Assist HKCR,"CLSID\{8C7461EF-2B13-11d2-BE35-3078302C2030}" HKLM,"SOFTWARE\Classes\CLSID\{8C7461EF-2B13-11d2-BE35-3078302C2030}" ; Component Categories cache daemon HKCR,"CLSID\{E56829C9-2D59-11d2-BE38-3078302C2030}" HKLM,"SOFTWARE\Classes\CLSID\{E56829C9-2D59-11d2-BE38-3078302C2030}" ; Component Categories conditional cache daemon HKLM,"Software\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskScheduler" ; (TESTING: this removes an entry of BROWSEUIPRELOADER too) HKLM,"Software\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskScheduler","{8C7461EF-2B13-11d2-BE35-3078302C2030}" ; ; MSHTML class key (TESTING) ; HKCR,"CLSID\{25336920-03F9-11CF-8FD0-00AA00686F13}" HKLM,"SOFTWARE\Classes\CLSID\{25336920-03F9-11CF-8FD0-00AA00686F13}" ; ; and this in addition to the two other taskscheduler keys ; HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}" - finally, found some duplicate occurances in ie.inf: HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved","{FF393560-C2A7-11CF-BFF4-444553540000}" HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}" HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}"
  17. Nope. ; AppWiz does not work as a cpanel applet without IE ; but it's needed to create shortcuts (.lnk). ; So put it in 'system' instead ;appwiz.cpl = 2,,,,,,,2,0,0 appwiz.cpl = 2,,,,,,,5,0,0 The above is in your txtsetup.sif. I made an alternate solution to this problem, by renaming appwiz.cpl to appwiz.dll, removed the reginst information inside the dll, and renamed some references to appwiz.cpl in INF files. After a few testing it turned out that some other dlls register lnk\shellnew to appwiz.cpl, so it might be ok if ie.in_ has some entries to remove these from registry ([FDVPATCH]) then recreate one with appwiz.dll. That's all. This way you will have no appwiz.cpl, ergo no "dead" control panel applet problem, but you can have appwiz.dll in system32, thus able to create those shortcuts if you want to. EDIT: Another idea, I can inject some registry info into my appwiz.dll to overwrite appwiz.cpl entry of .lnk\shellnew created by browseui.dll, but then it has to be registered AFTER browseui (if I remeber correctly it is the one)...Maybe from FDVPATCH Also I'm working on a slimmed down shell32.dll, with some registry junk removed too. When it's stable enough and there is interest i might upload it somewhere. Can be used through FIX folder. EDIT 2: I added these lines to ie.inf finaly, instead of hacking dll reginst: ; Task Scheduler Control Panel "applet" ; [color="#FF0000"]HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}"[/color] HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}" HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}" ... in progress @FDV I'm curious why haven't you added a remover for htmlfile and clsid 25336920-03F9-11CF-8FD0-00AA00686F13 (mshtml)? Till you answer I will try it of course maybe bluesrceen? EDIT 3: Is it possible to run the delreg section before addreg in IE.INF? (I would like to remove HKCR\htmlfile, and readd it with according how i want to - same applies to appwiz.dll)
  18. @FDV Look I made this thing: an appwiz.dll, hacked its registering and version info, and with some modification in HIVECLS.INF (.lnk appwiz.cpl -> appwiz.dll) , TXTSETUP, LAYOUT, SYSSETUP, it can be placed into system32, with no control panel applet, and a working shortcut creation. APPWIZ.zip
  19. @TC I would like to ask a big favor. Would you make me a "personalized" version of 1.2.2 with additional comments for "IF EXIST filname" blocks at the following places: :HFBLOAT :POSTHFX the INFCREATORS and SVCPACK It would be a great help to know what those processings are exactly.
  20. I'm making some test too. I will report back later. the custom strings are at the very begining of filter.txt By the way task scheduler issue is solved. The task scheduler registry key is created by a dll (shell32), not just by ie.inf by default. FDV's IE.INF is registered as RunOnce by hfslipwu.inf, to run its [FDVPATCH] section. Now that will occur AFTER shel32.dll gets registered, so the task scheduler entry in the delreg section re-removes the entry from the registry. If hfcleanup filters fdv-s ie.inf this issue occurs.
  21. I don't know. This is a hard question. I think I take a nap.
  22. @TC It obfuscates the code too much, makes it f* hard to maintain or read, take that in account too.
  23. @TP Hohoho Some test would be appropriate to see how many things were filtered by it. In the gfinder.zip I added some strings manually but mostly arbitary to see how big the difference can be, but I'm just curious what are the results in the "real life". I had an issue when I run hfcleanup, that hfslipwu.inf doesn't processed during install, so none of the runonce entries where added, so WINDOWS\HFSLIP folder had all the infs unprocessed and undeleted. This for example has not occured last time with /L, but i did not run all the removers (ZZZZs mostly. Then I tried another with all, but that install stopped. maybe because ZZZ_Englishonly, which I accidentally left in, despite the fact in WINNT.SIF I enabled Hungarian)
  24. hmm.. interesting, but sounds effective. What infs are these? does every component has an inf? I know that dfrg.inf is the defragger, but many other component's installer code is obfuscated by MS. I think that such parsing is not possible without accidentaly deleting other unwanted things, or not perfectly removing those which wanted. There is the problem with the current method, that it does not manage dependencies, but that could be solved by not fregmenting, but merging removal files, ie. merging dependig packages, and making a more complete removal on that area. I don't know. HFSLIPWU.INF
×
×
  • Create New...