NDIS Driver installation

My product is now including an NDIS 6.0 driver part of the installer, I like for it to install, and activate the driver. If at possible, it should only install and activate if a 10 Gbps card is found on the system, otherwise it will just go on with the rest of the software installation. Is this at all possible with NSIS?

Thanks

Do you know which SetupAPI/DeviceManager/COM API is required to figure this out?

Anders,

I do not. I only do the installation side of development. I spoke with our developer and all he said was its a network filter, not a network driver per se.

Once installed, its going to be an option found in the network properties of the actual device card(s).

or
http://superuser.com/questions/41295...onnection-over
or

maybe?

Though my developer now tells me long as the filter is installed, it can be installed and activated for all devices, so i guess now its back to how does one install the driver as all i have are myFile.cat, myFile.inf, and myFile.sys.

Also, I found I can use pnputil -a myFile.inf and it installs it, but doesn't activate it.

While you can find some driver threads here on the forum if you search for "driver", it is probably a good idea to check the WDK or ask on the OSR NtDev list to find out how you are supposed to install your type of driver...

Originally Posted by Anders View Post

While you can find some driver threads here on the forum if you search for "driver", it is probably a good idea to check the WDK or ask on the OSR NtDev list to find out how you are supposed to install your type of driver...

Sorry Anders, I was away on business and totally forgot about this and now its being pushed on me again with higher level of urgency. What exactly is the wdk or the OSR NtDev list?

I think worst comes to worse, I can do a shellexec to to the pnputil to install it, but since it doesnt activate might as well tell people to manually do it whch is also unacceptable. I think WinPcap may have had a similar behaviour when it installed itself? If I knew more I can probably know better what to ask but the devs themselves that made our driver isn't being that helpful to me right now unfortunately.

* DDK/WDK or whatever Microsoft is calling the SDK for writing drivers these days.

* http://osronline.com/showlists.cfm?list=ntdev

(Just using Google is faster than asking here when someone tries to give you some keywords to get you started)

Sorry didn't mean where it was, more meant what it was (for me) since I didn't develop the driver itself. But I will use their forums as a new starting point for this endeavour. I appreciate the help Anders.

For those that wish to follow this saga you can do so here...

Anders,

I discovered from the command prompt I can do this:

netcfg -l c:\foo\bar.inf -c s -i foobar

architecture is handled properly.
how do i actually execute this? neither works below

  ExecWait '"$sysdir\netcfg -l $\"$INSTDIR\foo.inf$\" -c s -i foobar"' $R3

  nsExec::Exec '"$sysdir\netcfg -l $\"$INSTDIR\foo.inf$\" -c s -i foobar"'

You need to quote correctly:

*Exec* '"c:\path\to\app.exe" /param1 "par am2" /param3'

How can I use -dash style params?

ExecWait '"$sysdir\netcfg.exe" -l "$INSTDIR\foo.inf" -c s -i foobar' $R1

Either way, with dashes or slashes it seems to do more, as rtasther than returning zero, i get a seemingly random string of integers back. but it still doesn't do anything.

if installer is running as admin, do child processes execwait spawns do they run as admin too?

I got this form the messagebox below it.
netcfg: 498157629

Yes a child process should be elevated.

Both Process Explorer (if the process stays around long enough) and Process Monitor will be able to tell you the exact command line netcfg is started with. Verify that the parameters (paths especially) are correct...

Okay.
it was something dumb.

C:\Windows\SysWOW64\netcfg.exe - not found.
do i force it to run as c:\windows\system32\netcfg.exe? i need the 64 bit mode allowed so it can work foir both architectures, right?

also do i need to say .exe?

i fohnd four entries.

C:\Windows\SysWOW64\netcfg.exe.exe

two with two exes and two with one exe.

Use x64.nsh to detect if you are under WOW64, if you are, execute it as "$windir\sysnative\netcfg.exe", this should work on Vista+, XP64 needs a patch for that to work.

".exe.exe" seems crazy, don't use that.

${If} ${AtLeastWinVista}

; deny windows 8.0, but allow 8.1 

  SetDetailsPrint textonly

  DetailPrint "Installing Foobar Filter..."

  SetDetailsPrint none

  ${DisableX64FSRedirection}

  ExecWait '"$sysdir\netcfg.exe" -l "$INSTDIR\foobar.inf" -c s -i foobar' $R1

This seems to had done the trick.
Is there a way to hide the command prompt window that pops up? At this point, it either works or it doesn't so error catching is least of my concern.
Since I need to work on OS restrictions for Vista and Above, but deny Windows 8.0 but allow Windows 8.1 for both architectures and handle XP the same way as windows 8.0 in fact.

Mainly besides hiding hte command prompt, i need to know if the logic assumes server vesions too?

# if ( currentVer => Vista && currentVer <= 7 || currentVer == 8.1 )
${If} ${AtLeastWinVista}
${AndIf} ${AtMostWin7}
${OrIf} ${IsWin8.1}

# do something

${Else}

# do something else
${EndIf}

Using ${DisableX64FSRedirection} is not a good idea (IMHO). If anything inside ExecWait needs to call LoadLibrary then it will fail. What is wrong with $windir\sysnative?

To hide the terminal window you have to use nsExec or one of the other exec plugins (on the wiki).

You should probably not combine ${AndIf} and ${OrIf} in one if statement, I don't know if that is officially supported. It is probably better to code it as "if (ver < Vista || ver == Win8 || ver == 2012) DoXP() else .."

The "ver == 2012" check is not really required since WinVer.nsh does not check the build number in the current implementation (Starting with Vista, build numbers change during service packs and client and server versions share the same major and minor numbers). 2003/2003R2 is the only server version that is out of sync with the client (XP) IIRC.

yes just found out it doesn't like that.
though it is saying _Or requires 4 parameters, and i gave it two.
i think that logic needs to be modified.
nothing is wrong with sysnative, i was unfamilar with its syntax.
so since i am using the 2.4 branch and williong to switch to 3 once i convince the devs about the path nonsense, but...

what do you recommend about detecting OS?

since during copying the files over, it already copiues the x64/x86 files appropiately so i dont need to check now.

Mainly I need to run the foobar.inf thing only if it is vista and newer with the exception of windows 8.0. 8.1 works, there is a bug in 8.0 that my dev said not to give it the new driver they built.

i dont know about servers just yet, but it needs to be back in my mind.

So essentially, Vista, Win7, and Win8.1 get foo; XP and 8.0 get bar.
I used to use the obsolete GetVersion plugin, so if im going to replace it all, i rather use the correct stuff and i had thought this method was the preferred way? thanks for all your help so far anders!

*AtLeastWinXYZ probably expands to several parameters.

*SysNative is just a fake folder that only exists for Win32 apps and it has the contents of the 64 bit $sysdir.

*I don't know what the path nonsense is. Plugin dirs?

*WinVer.nsh requires NSIS 3 to detect 8.1+ because Windows (GetVersionEx) lies unless the .exe has a 8.1 supportedOS guid in the manifest. For 2.4x, see http://forums.winamp.com/showthread.php?t=375267

From the old GetVersion page, it shows something similar about the manifest and a few other prerequisites. I think that may add too much work so maybe I will just go to 3.0. If I go to 3.0, regardless of the path issue, is 8.0/8.1 easier/better? Is that why my script is failing now or is there another logical error? I will have to resort that to make better without the crazy and/or if since there is no way to do a C-style compound if in nsis, correct?

* I still don't know what this path issue in 3.0 is, can you explain what you are talking about.

* 3.0 will handle 8.1 detection better because it has the correct guid in the manifest by default as long as you use RequestExecutionLevel. Unless you are still supporting Win9x it will also allow you to create Unicode installers and that can only be a good thing.

* If you need to mix and + or you can use nesting (might make the code complicated) or store some initial result in a register and then do the other operation.

Or just use this:

${If} ${AtMostWin2003}
${OrIf} ${IsWin8}
${OrIf} ${IsWin2012}
; DoXP
${Else}
; DoVista
${Endif}

It was about strlen. I used the old depreciated AddToPath plugin to push the program dir into the path. I did not hear from my dev team yet why it is even needed. far as i can tell, they have programs that scripts need to handle that are executed from outside the of directory. it was found in rare circumstance if the path was HUGE, it would erase it all. but now am thinking that might had been because i did $path = $instdir rather than += or something similar hence why i got the addtopath. i think once the path go to be too big, it did the same thing, it caused the entire path to vanish and only thing in it was the the instdir. it wasnt noticed until a few windows snapins failed to load because one of their critical paths was now missing (e.g., %SystemRoot%\System32\Wbem).

that being said, that was the only concern with the path, strlen.
no, windows Vista is now minimum software. 200 and older is now verboten.

i like your if better. thank you.

Anders,

Sorry again. What do I do with RequestExecutionLevel? And the ManifestSupportedOS?
This is where I found the special build I used where I got a bigger string length.

So... if I use the special build on the 3.0b I assume the path is "Safer" to manipulate again?

You should already have "RequestExecutionLevel admin" in your script. Unless you need the GUID for Windows 10 you don't have to use ManifestSupportedOS in NSIS 3.0 because it should be set to Win7+8+8.1 if the script uses RequestExecutionLevel.

Using the long string build does not fix the issue because the max size of %path% is even longer, it just makes the problem less likely to mess up the system. There are only two ways to update %path% in a safe manner; write a plugin or call the Windows API directly with the system plugin. The StrCpy instruction should never touch the contents of %path%...

Okay I will try to find some information that uses the Windows API.
I don't have Request. I had used originally the

!define ALL_USERS

method. but the installer does give me the shield for admin elevation already.

It will give you the shield without RequestExecutionLevel because NSIS is detected as a legacy installer without it. Your driver writers could probably write that plugin in less than one hour...

Just for reference: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

MSDN says to change system environment variables, add them to the 'Environment' key in the registry and send a WM_SETTINGCHANGE message. Alot of the process is absolute, so the bit that will take the coding time is string processing (I'm only looking at checking/adding/deleting a single path, not the entire contents of a value).

Sounds simple enough, I might have a crack at a plugin in the next couple of days, no promises though 🙂.

It took me ages figuring out how to walk along strings from different positions, turns out the code is rather simple once it's cleaned up (it's cool watching the strings change with every message box that comes up).
Check the attached screenshot, I'm getting excited 😁 😁.

...
len = lstrlen(pPathString);
pPathString[len] = ';';
pPathString[len+1] = '\0';
if (StrStrI(gpBuf, pPathString))
return 0;
if (StrStrI(gpBuf, pPathString) == NULL)
{
int i, i2 = 0;
i = lstrlen(gpBuf);
while (i2 <= lstrlen(pPathString))
gpBuf[i++] = pPathString[i2++]; //, MessageBox(NULL, gpBuf, &(pPathString[i2]), MB_OK);
}
...