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. ×

Geej

Member
  • Posts

    635
  • Joined

  • Last visited

  • Donations

    $0.00 

Posts posted by Geej

  1. You could add this code in Launch.bat to detect win7 as you did for earlier OS version.

    (and remove those few lines using systeminfo command.

    ver | find "6.1" > nul
    if %ERRORLEVEL% == 0 goto ver_7

    For win7.bat, I made these small changes

    @ECHO off
    CD %~dp0 <-----new code
    CD..
    CD "apps/winrar/"
    ECHO Installing WinRAR
    start "winrar" /wait winrar.exe /s <-----modify code
    cls
    ECHO WinRAR Installation completed !

    Note: I tested under VM win7x86 with winrar.exe only. (I have admin-right with UAC enabled)

    I still get UAC warning prior to install winrar.exe

    If I allow to install, Winrar installed successfully.

    Cheers

  2. It sounds like some corruption is causing my problem, but how to uninstall 9.5.3?

    I have some limited knowledge for Adobe reader 9 registry entry.

    You can inspect the registry location in the following inf first.

    The inf is to restore Adobe reader 8,9,10,11 to a uninstallable state if some pdf program breaks Adobe reader install/uninstall routine.

    I strongly suggest before you 'right-click' the inf, and select 'Install', do a manual backup of these registry

    location in case you wish to restore back to where you are before you run this inf. (Your milegae may varies)

    The registry location I said to make a backup are in the INF.

    After run the inf, use Add/remove panel to remove Adobe reader 9. (I assume you can still launch the Adobe Reader 9 uninstaller)

    Hopefully it will works.

    RestoreAdobeRdr9.txt

    Rename RestoreAdobeRdr9.txt to RestoreAdobeRdr9.inf

    ;Restore Adobe Reader 9
    [Version]
    Signature=$Windows NT$

    [DefaultInstall]
    AddReg =REGEntries.AddReg

    [REGEntries.AddReg]
    HKLM,SOFTWARE\Classes\.pdf,Content Type,0x0,application/pdf
    HKLM,SOFTWARE\Classes\.pdf,,0x0,AcroExch.Document
    HKLM,SOFTWARE\Classes\.pdf\OpenWithList\AcroRd32.exe,,0x10
    HKLM,SOFTWARE\Classes\.pdf\OpenWithList\AcroRd32.exe,,0x0

    HKLM,SOFTWARE\Classes\MIME\Database\Content Type\application/pdf,Extension,0x0,.pdf
    HKLM,SOFTWARE\Classes\MIME\Database\Content Type\application/pdf,CLSID,0x0,{CA8A9780-280D-11CF-A24D-444553540000}

    HKLM,SOFTWARE\Classes\MIME\Database\Content Type\application/vnd.fdf,Extension,0x0,.fdf
    HKLM,SOFTWARE\Classes\MIME\Database\Content Type\application/vnd.fdf,CLSID,0x0,{CA8A9780-280D-11CF-A24D-444553540000}

    HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\PreviewHandlers,{49400A7C-81A8-4F52-8CCE-D54739EE87EC},0x0,Adobe PDF Preview Handler
    HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\PreviewHandlers,{DC6EFB56-9CFA-464D-8880-44885D7DC193},0x0,Adobe PDF Preview Handler for Vista

  3. This article says "DefaultInstall sections must not be used for device installations. etc" in the 'Remarks' heading. It also says try calling using InstallHinfSection.

    But also this article says as long as there is an INF Manufacturer section, it generally will also work.

    We have the section in tplcd.inf

    [Manufacturer]
    %Lenovo%=Lenovo,NTx86,NTamd64

    Perhaps we can try calling InstallHinfSection on commandline (w/o using infdefaultinstall.exe)

    rundll32 setupapi,InstallHinfSection D:\@Drivers\$T500\$Common\Video\LCDMon\geoi02w8\tplcd.inf

    Above are just pure guess on my part.

  4. Seems like Obj.AddressWidth method is much easier in vbscript. (in Post #20)

    vbscript is not something I look or consider scripting as my first choice of language, also there are always so much to learn...

    How difficult is the single line batch/comand using WMIC I posted in post 21?

    Certainly not hard at all. I always have this "WOW' or "awesome" feeling for a single line code.

    I wonder why David Wang comes up with such a confusing method using batch. He certainly confuse me :)

  5. bphlpt is right in David Wang's case. I realise I got it wrong.

    Base on bphlpt's post #10 detection logic and also Yzöwl's post #18 batch logic,

    and using GSM post #11 code but slighly modify, I think the vbscript should look like this:

    Dim Act :Set Act = CreateObject("Wscript.Shell") 
    Dim SysVar : Set SysVar = Act.Environment("System")
    If SysVar("PROCESSOR_ARCHITECTURE") = "AMD64" OR SysVar("PROCESSOR_ARCHITEW6432") = "AMD64" Then
    WScript.Echo "x64 OS bit"
    else
    WScript.Echo "x32 OS bit"
    End if

  6. Since David Wang post caption is "HOWTO: Detect Process Bitness"

    and bphlpt also quoted from his post it is "The logic that I use from a program to detect whether the OS is 32bit or 64bit looks like this:"

    So here we have a conflict of information from his post.

    However, MSDN post is that PROCESSOR_ARCHITEW6432 is an environment variable use in 'WOW64 Implementation Details (Windows)'

    Here is another quote ss64.com where he quoted David Wang post too. (But look at the title: it is 32 bit or 64 bit process detection)

    Hence the batch file is really a process bitness check, not OS bitness.

    Just to lighten this discussion, MS also provide an article how to determine whether a computer is running a 32-bit version or 64-bit version of the Windows operating system.

    The best part of it is in the 'Next Steps'. (Call support if unsure, LOL)

    Regards

  7. Why are we checking the value of %PROCESSOR_ARCHITEW6432% in a batch file?

    Does it affect the OS bitness result?

    My common sense tells me since %PROCESSOR_ARCHITEW6432%'s value is dynamic, it makes no diffenece checking this value that will affect the result of OS bitness.

    But OS bitness is static. Will this dynmanic value affect a static value?

    Shouldn't we be checking something that has a static value and consistent throughout the lifetime while the OS is up & running?

    Just another thought...

  8. PROCESSOR_ARCHITECTURE6432 comes into picture only when 32-bit application is running on x64 OS.

    You might find this MSDN article useful.

    It describes how x64 OS handles 32-bit applications.

    Running 32-bit Applications (Windows)

    Also read 'WOW64 Implementation Details'. It mentions PROCESSOR_ARCHITEW6432 environment variable.

    In short, PROCESSOR_ARCHITECTURE6432 is not a variable to check your OS bitness.

    PROCESSOR_ARCHITECTURE6432 is (as I see it) transparent to the user as it is how the operating system handles internally 32-bit program within a x64 os.

  9. inf detection logic

    Just right-click ChkOSbitness.inf and "install"

    [Version]
    Signature=$Windows NT$

    [DefaultInstall]
    RegisterDLLs=Start.Register

    [Start.Register]
    11,,rundll32.exe,,,"advpack.dll,LaunchINFSection %1%\%infname%.inf,Install"

    [Install.ntx86]
    RunPostSetupCommands=echo86

    [Install.ntamd64]
    RunPostSetupCommands=echo64

    [echo86]
    cmd /c echo x86 section is called & pause

    [echo64]
    cmd /c echo x64 section is called & pause

    [Strings]
    infname=ChkOSbitness

  10. I think gunsmokingman method using Obj.AddressWidth is good enough. (post #9)

    Here is another one liner code using Obj.AddressWidth I found.

    The importance of checking bitness is to know the OS's bitness, not CPU bitness.

    Correct me if I'm wrong, since we can't install x64 OS when CPU is only 32-bit-capable, it makes sense to check OS bitness only.

    As I also noted, INF has .NTx86, .ntamd64, .ntia64 or .nt section

    These sections are purely base on OS bitness.

    Hence what is important during installation is the OS's bitness, not CPU's bitness.

    For the OP initial problem ("Cannot find the file specified"), I think we can simply further using oShell.CurrentDirectory (like cmd pushd command)

    Just my thought...

  11. Come to think of it, I think the best way to create shortcut silently is to use OCT 2007 (office customization tool), if you are using it.

    It allows to create desktop shortcut. Better than any script, IMHO. During uninstall, at least it is able to remove it.

    For reference, scroll (3/4 down the page) to 'Add/Modify Shortcut Entry dialog box' -> 'Location' for various shortcut location.

    Best regards

  12. Here is my MSOfficeSc.inf for Word & excel 2007 (works for x86 & x64 within 1 inf)

    Command line usage is at the end of inf

    ; Word & Excel 2007 Shortcut on all users desktop

    [Version]
    Signature=$Windows NT$

    [DefaultInstall]
    RegisterDLLs=Start.Register

    [Start.Register]
    11,,rundll32.exe,,,"advpack.dll,LaunchINFSection %1%\%infname%.inf,Install"

    [Install.ntx86]
    ProfileItems=WordSC, ExcelSC

    [Install.ntamd64]
    ProfileItems=WordSC64, ExcelSC64

    [WordSC]
    Name =Word 2007,0x8,25
    CmdLine = 16422,Microsoft Office\Office12,WINWORD.EXE
    WorkingDir = 16422,Microsoft Office\Office12
    InfoTip ="Create and edit professional-looking documents such as letters, papers, reports, and booklets by using Microsoft Office Word."

    [ExcelSC]
    Name = Excel 2007,0x8,25
    CmdLine = 16422,Microsoft Office\Office12,EXCEL.EXE
    WorkingDir = 16422,Microsoft Office\Office12
    InfoTip = "Perform calculations, analyze information, and visualize data in spreadsheets by using Microsoft Office Excel."

    [WordSC64]
    Name =Word 2007,0x8,25
    CmdLine = 16426,Microsoft Office\Office12,WINWORD.EXE
    WorkingDir = 16426,Microsoft Office\Office12
    InfoTip ="Create and edit professional-looking documents such as letters, papers, reports, and booklets by using Microsoft Office Word."

    [ExcelSC64]
    Name = Excel 2007,0x8,25
    CmdLine = 16426,Microsoft Office\Office12,EXCEL.EXE
    WorkingDir = 16426,Microsoft Office\Office12
    InfoTip = "Perform calculations, analyze information, and visualize data in spreadsheets by using Microsoft Office Excel."

    [Strings]
    Infname=MSOfficeSc

    [commandline]
    rundll32.exe advpack.dll,LaunchINFSection MSOfficeSc.inf,install


×
×
  • Create New...