YumeYao
Content Type
Profiles
Forums
Events
Posts posted by YumeYao
-
-
Hi Gora,
I had posted a question on the previous page (13) about getting the return code of an executable run by 7zSfx. I've downloaded, modified and compiled the source, but I've run into a problem linking to msvcrt.dll.
Your official released version of 7zSfx links to msvcrt.dll and not to any of the VC++ version specific MSVCrt DLL files (eg, msvcr100.dll). This is good, as it means that machines don't need to have a specific version of the VC++ Redistributable installed for 7zSfx to work on them. I want to replicate this behavior, which does not appear to be the standard for VC++ setups.
From reading about this issue, it appears to be solved by linking to a specific version of the msvcrt.lib file, one that links to msvcrt.dll and not any of the other DLL files. I've tried the version that comes with the Windows Driver Developer Kit, and although the stub compiles fine, it only executes on Windows 7 machines (appears to require the Windows 7 version of msvcrt.dll).
I see in config.cpp that you have pragma links to msvcrt.lib in "C:/Mobile/Develop/Lib/VC8/<platform>/msvcrt.lib" - could you tell me exactly what versions of msvcrt.lib those are? Are they the versions provided with VC++ 2005? My development box has VC++ 2008 (on Windows 7) so maybe that's the problem... would you by any chance be able to temporarily provide me with a download link to those two .lib files?
Failing that, if I provided you with the two extra lines of code to capture and report the return-code of the last run executable, could I persuade you to build me a custom version of the current stable LZMA 32bit stub?
Cheers!
John
Get WinDDK 2003 SP1 and use the CRT headers from it and lib (msvcrt.lib) from it.
Additionally, if you have VC6, you can use the lib from it. (But the CRT header should be from DDK 2003 SP1 or Win7 DDK for bug-free).
0 -
BUG on macro _SFX_USE_LANG. (Version 141_2100)
main.cpp
AString strSignatureBegin;
AString strSignatureEnd;
#ifdef _SFX_USE_LANG
CreateLanguageSignature( idSfxLang, strSignatureBegin, strSignatureEnd );
#endif // _SFX_USE_LANG
if( ReadConfig( inStream, strSignatureBegin, strSignatureEnd, config ) == false ) /* DANGER!!!! arg2 and arg3 not inited!!!! */
{ /* BUG!!!!! NEVER REACH HERE!!! Because ReadConfig Easily Find the Signature of NULL and consider it have found the signature. */
if( ReadConfig( inStream, kSignatureConfigStart, kSignatureConfigEnd, config ) == false )
{
SfxErrorDialog( FALSE, ERR_READ_CONFIG );
return ERRC_READ_CONFIG;
}
}This code will leave strSignatureBegin and strSignatureEnd not initialized and therefore the sfx doesn't work.
The fix I'm using:
#ifdef _SFX_USE_LANG
AString strSignatureBegin;
AString strSignatureEnd;
CreateLanguageSignature( idSfxLang, strSignatureBegin, strSignatureEnd );
if( ReadConfig( inStream, strSignatureBegin, strSignatureEnd, config ) == false )
// if fall through
#endif // _SFX_USE_LANG
if( ReadConfig( inStream, kSignatureConfigStart, kSignatureConfigEnd, config ) == false )
{
SfxErrorDialog( FALSE, ERR_READ_CONFIG );
return ERRC_READ_CONFIG;
}0 -
Making the script is another thing, for example, I have to make seperate .mst's for each language pack, rather than a generic tutorial(same steps).
Maybe I could give it a simple edit to support slipstreaming latest updates.
Also there are many limits with the cmd command. I have added a lot of features in my pack, as you can see:
1. updates are listed out in ARP.
This requires: the msp, the vbscript, then the mst.
msp can't be made by cmd easily(or accurately the pcp, patch creation property), neither can the mst.
2. updated files.
Should I include the updated files in the pack(if I could ever update SNMsynth with full functionality), or should I suggest downloading them? The original packages are probablly up to 1GB.
3. use external tree instead of admin external
The other features may be added by the means of cmd and mst, i guess.
In total, I find that a tutorial is much easier(for me to write) and help experienced and knowledged people understand the msi package and the .NET package narrowly.
0 -
NDP20SP2-KB983583-x86.exe superseded NDP20SP2-KB976569-x86 which in turn superseded NDP20SP2-KB974417-x86, you have to look at what files are included in the update.
Yes that's correct.
But the blocking of KB974417 is still essential. Don't worry it's done by SNMsynth
0 -
Removing __CxxFrameHandler3(MSVCRT.DLL) dependency on x64:
This entry point is available in MSVCRT.DLL of Windows7 x64/Windows Srv 2008 R2, but unfortunately, it's missing in MSVCRT.DLL of Windows XP/2003 x64.
After searching, I found this post:
One reply suggests:
extern "C" void *__CxxFrameHandler;
extern "C" void __declspec(naked) __CxxFrameHandler3(void)
{
// Jump indirect: Jumps to __CxxFrameHandler
_asm jmp __CxxFrameHandler ; Trampoline bounce
}It's good enough on x86, I suppose you may consider using that in your Exceptions.cpp, replacing your extern "C" void __CxxFrameHandler3. Yet x64 compiler doesn't support _asm and the keyword "naked". So you have to use the bloated C code on x64:
extern "C" void *__CxxFrameHandler( PEXCEPTION_RECORD rec, void * frame, PCONTEXT context, void ** dispatch );
extern "C" void __CxxFrameHandler3( PEXCEPTION_RECORD rec, void * frame, PCONTEXT context, void ** dispatch )
{ __CxxFrameHandler( rec, frame, context, dispatch ); }I have tested it and it passed the linking with an old MSVCRT.LIB. You could look at this and try making some exceptions while executing/debugging, to see whether this works, and consider using it in your next version.
-EDIT-
Added a screenshot:
0 -
@geromichi & strel,
I'll probably use uiautomationcore.dll and .mui from Vista(WinSrv2008)-KB971513. Why I don't that file from XP is because it breaks it's multi-lingual support, coming with built-in language resources. But I havn't done tests yet.
@strel,
in my test of SNMsynth, KB958484 doesn't have its files updated in .NET 3.5(files are still with build number 1), but entries are present in vs_setup.msi. I think you may applies *.msp earlier than NET35SLIMDOWN.mst.
there are still other improvements that could be made, I'm not at home so I'll write later.
0 -
Thanks strel, I'll check it.
BTW, you missed the title: it should be 20091029, not 20090929.
EDIT: OMG, so many *.mst's, I know it must be hard work. thanks again.
0 -
@moons:
you can use my chinese installer (link or sp3only), extract it and replace language packs with yours, then repack it. Only that SNM won't slim down 3.5 LNG pack for you, if you need it and don't understand how to do it yourself, leave a post here, I'll help you with it.
@strel:
can you introduce to us what the progress is for next release. I know I have written too much on it.
0 -
back from tests. Removing those components can reduce the final 7-zip size by 0.8MiB around, and doesn't harm on xp/2k3 at all.
0 -
I see. You don't apply KB951847 fix to windows 2000 in the SNM script....
0 -
some new thoughts after I did a test on windows 2000:
1. There are some files in .NET 2.0 only needed by windows 2000, if we could remove them then the size would be smaller for XP/2k3. I decide to remove all components with condition NOT (VersionNT > 500) yet i haven't done a test yet. I'll let you know the result.
EDIT: .NET 1.1 also has such files. but I don't intend to install .NET 1.1 any longer.
2. Is it possible to create a generic mst that removes components such as KBxxxxxx.ARP.NoRemove & KBxxxxxx.ARP.Add? They cause the issue that 2000/XP SP0/XP SP1/2k3 SP0 shows KBxxxxxx for .NET entries on ARP. I decide to manually move them in my release, however.
3. For 2000, KB951847 fix is not needed. KB971111 doesn't require a fix too(WU checks gdiplus.dll version).
The only need is KB974417 fix (plus language pack fix for 2.0).
Therefore I'm going to make a new mst for .net 2.0 to avoid useless registry entries on windows 2000.
0 -
Hi,
Could you update snmsynth 20090922 so that it takes into account the new update (NDP20SP2-KB974417-x86.exe)?
I tried this version but the update is requested by Windows so I think it did not work ....
Thank you in advance
I guess strel is busy IRL. If needed I can help update his script.
0 -
As I have not yet seen the latest Windows 2000 specific patches listed in this thread, I'd best mention them:
For .Net 1.1 sp1:
dotnetfx.exe
NDP1.1sp1-KB867460-X86.exe
NDP1.1sp1-KB953297-X86.exe
NDP1.1sp1-KB971108-X86.exe Required for W2K (replaces KB947742)
For .Net 2.0 sp2:
NetFx20SP2_x86.exe
NDP20SP2-KB958481-x86.exe
NDP20SP2-KB974417-x86.exe
NDP20SP2-KB971111-x86.exe Required for W2K
good info. thanks dude.
0 -
yes, it's ok as far as it's added at any time after .NET installation.
0 -
you can save it as *.reg, and merge it into your registry.
0 -
sorry for late replying, I am a little busy these days.
What strel said is not correct on the new KB974417, we still need a reg fix if we pre-apply msp to the install package.
It's totally similar as how we block KB95848x.(KB951847).
The key is:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\DC3BF90CC0D3D2F398A9A6D1762F70F3\Patches\9E0DE89293FE9BB33898F24ED18CCF08"
Add this key, then a dword value "State"=0x1 under it.
the key name in "patches" can be calculated like this:
This is also a generic way to convert a GUID to plain text.
best regards.
0 -
@strel
on the WIC issue:
its update.inf doesn't contain any entry calling spupdsvc.exe. This is also the first time i see such a hotfix with spupdsvc.exe yet doesn't call it.
here is also a simple test to prove it.
environment is xp sp2 chs.
@dumpydooby
I always do a test on perfectly clean system before I confirm all is working.
0 -
good info.
Then it seems:
DW fix is not needed for we removed office debugger.
SSIP fix is (possibly) not needed for VC8 assemblies are initialized during txt-setup mode(if proper addon is integrated). I'm not sure and I havn't done any test for this.
0 -
I see your post at strel's SNMsynth, did you use his script to install all the stuffs?
so can you try without his script? because I can't find any thing wrong in your vs_setup.msi excpet for ARPSYSCOMPONENT.
EDIT:
sorry I got it wrong. well, you applied his NETWUFIX.mst, then you HAVE TO use his script otherwise it'll be not uninstallable.
0 -
what's the error? how did the dialog pop up?
0 -
Hi YumeYao.
I had no time last days to make tests I'm beginning now. About your proposals:
1. I'm using your fixed method to apply new update shell to WIC and XPS. You say "safer" to only use the update shell from this hotfix, probably, but is there something I should know?
1. yes. My first method(branches) will bring a result that proper catalog is not installed on xp. My second method is a fault because it won't installs on xp sp3(I was working on xp sp2 those days so....).
Now I uses a modified inf and a patched update.exe for my release. If you don't want to use the patched one, you can apply my second method on KB971276-XP-V3(I didn't test that on 2k3 but I suppose it works). If that doesn't work, then using KB971276-XP and KB971276-2003 seperately is the safest way.
Still, I mean replace all update shells with the one in original XPS printer because those in XPS printer are latest.
- Well I'm splitting NETWUFIXES but I'm making it even more atomized, and scripts will not be touched. I'm trying to pre-apply all transforms also to avoid .mst extra files in the installer packages and later cached when installed. This means, that 3.0 langpack extra values you added methodicly (InstallSuccess and Version, resembling 2.0 langpack values), but not checked by win/ms update, will not be included. It can be expected update system will keep cheking the same values. And you're not applying those 3.0 extra values in the right regkey with your VBS scripts. Check Registry table of a 3.0 langpack installer to compare.About INSTALL.CMD script. (I only checked .doc version suppose it's equal to .docx)
- About renaming the cached installer, this lines will be kept, as well as VBS ones. As I said before, original installers always use same file names for cached installers, and while you pointed right the update system don't check them and that you can manage new names, maybe other software could rely on them, and I'd like to keep as much as possible things untouched to avoid potential problems (I'm not referring with this to .msi installers and fixes applied obviously)
I'll test about the .msi cache names. I didn't notice what you said "original installers always use same file names for cached installers". If that's true, then I'll agree with you.
EDIT2: tested and here's a screenshot:
what you said does not happened.
so you can take a look at my msts and vbses, they will handle this issue properly.
- About delaying 3.0 subcomponents install to logon, I'm using RunOnceEx entries instead of a RunOnce script, thus I'm able too to rise up its related dialog about what's installing, executing it first before any other software installing from there (unless rare regkey names applied), but only in case verbosity is not silent. And I don't get why are you relying on SSIP setting to switch to delayed installing. I understood from what you told, both XPS and WIC were executing spupdsvc.exe in every circumstance, so what SSIP has to do with this? I suppose you're not installing WIC, hence delaying it because your script is for XP SP3.On a live system it's always safe to execute spupdsvc.exe(consider how user installs hotfixes). Only on a system-setup-in-progress OS, it may damage. So I determinate it with SSIP.
RunOnceEx is also ok.
WIC won't execute spupdsvc.exe, that's why I doesn't make it RunOnce-delayed.
I'm beggining my tests now, hope all the above can be achieved.good luck.
EDIT: forgot to say. look at this:
http://catalog.update.microsoft.com/v7/sit...aspx?q=KB951847
This 69.2 MB stuff is not same as the one in download.microsoft.com, if you can make your script compatible for this one, that will be good.
@ YumeYao.I only integrated this one:
sorry, I can't see the reason why your install fails. All I use is also code's addon.
0 -
I'm using RogueSpear's install script.
I removed the installation of WIC from it because you said earlier that it's not needed with SP3.
I also removed the installation of RGB9RAST_x86.msi, preferring instead to manually copy the DLL and register it (this is done by the SFX).
The meat and potatoes of the install script are as follows:
ws.Run("dotNET30SP2\XPSEPSC-x86-en-US\update\update.exe " & txtArg2 & " /nobackup /norestart"),0,True
ws.Run("msiexec.exe /i dotNET30SP2\Netfx30a_x86.msi " & txtArg1 & " REBOOT=ReallySuppress"),0,True
ws.Run("WaitNET.exe " & txtArg1),0,True
ws.Run("msiexec.exe /i dotNET35SP1\vs_setup.msi " & txtArg1 & " REBOOT=ReallySuppress"),0,True
ws.Run("WaitNET.exe " & txtArg1),0,True
ws.Run("regedit.exe /s KB959209.reg"),0,True
ws.Run("dotNET35SP1\KB971276\update\update.exe " & txtArg2 & " /nobackup /norestart"),0,True
ws.Run("dotNET35SP1\KB961118\update\update.exe " & txtArg2 & " /nobackup /norestart"),0,True
ws.Run("dotNET35SP1\KB971314\update\update.exe " & txtArg2 & " /nobackup /norestart"),0,True^where "txtArg1" and "txtArg2" are "/qb" and "/passive"
Here are my MSIs:
http://xp.xpdnc.org/files/WIP/vs_setup.msi
http://xp.xpdnc.org/files/WIP/Netfx30a_x86.msi
I've created half a dozen or so, using various methods and source files. The above ones, though, were taken directly from the official 231MB "dotnetfx35.exe" file from Microsoft. I then processed the files using Strel's program. Afterwards I ditched his install.cmd script, applied the transforms to the MSIs permanently, and used the installation script seen above.
I've also tried following the guide on an untampered vs_setup.msi without using Strel's program, just doing it manually with InstallShield, but that didn't work out either.
And I tried following the guide on RogueSpear's vs_setup.msi file ... again, didn't work.
All of these methods seem to install it just fine. I've tested with various .NET programs (including Paint.NET). The problem is that none of them yield a product that is uninstallable.
How difficult would it be for me to just take your package from the first post and make it uninstallable? Do you know what I would need to do to accomplish that?
ok.... simply you missed step 7 in my tutorial..
7. go to Property table, remove 2 entries: INSTALLLEVEL and ARPSYSTEMCOMPONENT.
0 -
I finally worked out the whole thing as I wanted. Tested on VM and worked fine. Here are my final decisions to share:
- for KB971276, I finally think it's safe to use original one.(WindowsXP-KB971276-v3-x86-ENU.exe for XP, WindowsServer2003-KB971276-v2-x86-ENU.exe for 2k3). But the hotfix update shell replacement is harmless and can be applied to reduce size.
- on msi:
- CA_BlockDirectInstall* in CustomAction and InstallExecuteSequence prevents msi from direct install. Removing them ensures the msi can be installed without "ADDEPLOY=1".
- .NET 2.0 specific: DWFolder.D0DF3458_A845_11D3_8D0A_0050046416B9 and needed parents should NOT be removed in Directory, it's needed by debugger registry(DW20.exe).
- on mst:
my final working set is here. workingmsts.zip - on install.cmd:
modifiedinstallcmd.7z
EDIT: I have changed some paths.. be careful. as far as i can see, I didn't restore the path for XPS_LanguagePack in the document.
EDIT2: @Raul90
Have you integrated VC2005/2008 runtimes when you are doing a test?
0 - for KB971276, I finally think it's safe to use original one.(WindowsXP-KB971276-v3-x86-ENU.exe for XP, WindowsServer2003-KB971276-v2-x86-ENU.exe for 2k3). But the hotfix update shell replacement is harmless and can be applied to reduce size.
-
Hi gora and other member please test and improve help file
this a googled help file and included 2help file 1.7zSD_en.chm 2.7zSD_en.chm
i vote to use 1.7zSD_en.chm
http://rapidshare.com/files/286711828/en.cab.html
MD5: 6E55406C85B7C8771E1EBE75CF8ACC5A
Not good as expected. Anyhow I vote to using 1.7zSD_en.chm too, since its layout is better than 2. So isn't there any member who knows both Russian and English well? One of my high school classmates majors Russian in college, I think I should ask her for help.
0
7z SFX Modified Module and Tools
in Application Installs
Posted · Edited by YumeYao
I just built a self-made version for my need yesterday and I encountered this bug so I just fixed it. It's really dangerous because people who want to turn it off will and doesn't test it will have the wrong sfx then wrong exe.
BTW, I have several suggestions( some already done by me locally) to you:
I see you're actually telling dialog version apart from non-dialog version by looking for the dialog resources, in other words, the code is same.
I think you may want to let user manually add dialogs to versions other than LZMA, but this is not documented.
Anyway, in my self-made version, I modified the code to fully disable dialogs, reducing the sfx by 1.5KB.
Not to be offensive, but I don't think it's good to add them in the code, or we may need a macro to turn it off. The strings takes too much spaces.
Also, you may think save langstrs.cpp as UTF-8, so that users using other languages can compile it without modifications.
Well, I tried adding it but failed. But I have some solutions that may work:
Getting the Width:
1. Set RTF Control to max width(as the window allows)
2. Get line count. (EM_GETLINECOUNT)
3. Set RTF Control to (it's previous width)/2
4. Get line count, if equals to previous, goto 3, otherwise goto 5
5. Set RTF Control to (it's previous width)-10
6. Get line count, if equals to previous, goto 5, otherwise goto 7
7. Set RTF Control to (it's previous width)-1
8. Get line count, if equals to previous, goto 7, otherwise goto 9
9. Done. Previous width(=current width + 1) is what we need.
Getting the height:
1. Get the text
2. Add "\par " to the end. (There must be 2 spaces, first space is omitted because it follows a \par.)
3. Set the text.
4. Get line count. (EM_GETLINECOUNT)
5. Get line index of last line(last return value -1). (EM_LINEINDEX) This index is the white space we just added.
6. Get the position of the white space (EM_POSFROMCHAR), the y-offset is the height.
7. Restore the text to before to not make user confusing(using arrow keys can move the cursor to the invisible white space).