cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
JoderCoder
Level 8

Hardware information

Is there any other hardware msi properties than following?
Alpha
BorderSide
BorderTop
CaptionHeight
ColorBits
Intel
Intel64
Msix64
PhysicalMemory
ScreenX
ScreenY
TextHeight
VirtualMemory

I need to access the system' s hardware to see it is meeting the minimun requirements.

Installed RAM -512 MB for XP 1024 for Vista
Free disk space - 120 Mb
CPU speed/type - 2.4ghz pent4
Video Card - DirectX 9.0c Compatible Graphics card with at least 32 MB Free Video RAM (64 MB for Dual Headed Configurations)
I/O ports - USB 2.0 port

RAM is ok, I can use PhysicalMemory for that. How about the rest?

Any pointers are appreciated!
Labels (1)
0 Kudos
(15) Replies
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

Disk space requirements are automatically checked by the InstallValidate action. If you need to reserve more space than the installation actually requires, you can add records to the ReserveCost table in the Direct Editor.

For CPU speed/type, video card information, and I/O port information, it would be necessary to use a custom action to query the machine for this information. Windows Installer does not provide any predefined properties containing this information.
0 Kudos
JoderCoder
Level 8

Thanks a lot!

I would think this kind of job would be quite often for installers. Does anyone know of something I could re-use or start with? That would save me a lot of time, rather than browsing in MSDN for hardware APIs.

Thanks again!
0 Kudos
JoderCoder
Level 8

I found a script if someone ever needs this. Here, via WMI , I read CPU speed for example.

Set objWMIService = GetObject( "winmgmts://./root/cimv2" )

Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Processor")

For Each objItem In colItems
strMsg = strMsg & objItem.Name & vbCrLf & " - Current Clock Speed = " & objItem.CurrentClockSpeed & ", " & "Max Clock Speed = " & objItem.MaxClockSpeed & vbCrLf
Next


WScript.Echo strMsg
0 Kudos
DLee65
Level 13

Just beware if you are using vbscript for custom actions. The reason is because they can be flagged by antivirus software. Some users can lock out vbscript completely and that will generate innocuous Windows Installer errors.

If you are not creating software for commercial distribution, or you know the client who will be receiving the software then this option may have greater merit.
0 Kudos
JoderCoder
Level 8

Hmm, thanks a lot for the heads up.

What is the suggested Custom Action type for packages for corporate deployments to make sure all the customers can run the CA's with no problems? Could Jscript have the same potential problem as VB? How about a C++ dll or managed code like C# though I wouldnt personally prefer them.
0 Kudos
Christopher_Pai
Level 16

JScript has the same issues because it's still based on ActiveScript just like VBScript.

InstallScript can do what you want and the engine is quite reliable these days. Still, it doesn't have a collection enumerator so writing simple for..each loops is a pain; you have to use a DLL you can find on InstallSite.

C++ has the least amount of dependencies so it's very reliable, although it's also a pain to write.

If you don't mind having a dependency on .NET 2.0 or greater, WiX DTF using C# is the only way to fly in my opinion.
0 Kudos
DLee65
Level 13

Here is a small InstallScript project I did a couple of years back that checks for processor information, memory, etc that can be adapted if desired. It may not be what you are looking for but we had designed it to do a more exact check of system requirements for our prerequisites.
0 Kudos
JoderCoder
Level 8

Thanks a lot, Dan!
0 Kudos
JoderCoder
Level 8

Christopher Painter wrote:


If you don't mind having a dependency on .NET 2.0 or greater, WiX DTF using C# is the only way to fly in my opinion.


Hi Christopher, do you foresee a problem wrt managed code dlls from Microsoft? I found this article in a blog:

http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx

I have to make a language choice to write my Custom Actions, not only for this hardware one, but for all of the Custom Actions I have. VB seemed really easiest way for me but it has the potential problem for corporates that block executing VB scripts, that is pointed out earlier. .Net option seems little bit easier than C++.

Please let me know your thoughts. Thanks!
0 Kudos
JoderCoder
Level 8

DLee65 wrote:
Just beware if you are using vbscript for custom actions. The reason is because they can be flagged by antivirus software. Some users can lock out vbscript completely and that will generate innocuous Windows Installer errors.


If we store the Custom Action in the binary table, then is this still a potential issue?
0 Kudos
Not applicable

InstallShield also has built-in support for managed custom actions that offer slightly different advantages versus DTF. Each pattern is viable and you can find more information by searching these forums.

To address your concern raised about DLee's point, the answer is "Not likely".

For more information on why VBScript custom actions should be avoided, see this:
http://blogs.msdn.com/robmen/archive/2004/05/20/136530.aspx
0 Kudos
Christopher_Pai
Level 16

I don't believe it matters if the script is stored in the binary table, it still gets written out to a tempory file before executing so it can still become clobbered.

I suppose the only 2 real advantages to InstallShield's Managed CA pattern are:

1) If consuming an existing managed API, there is no reason to write a wrapper class to adapt it to MSI

2) There's some really nice reflection capabilities in InstallShield to map the properties to the class/method.

However there are a couple disadvantages:

1) Tatooing the msi process with the CLR version
2) Vastly inferior interop API

In the end, creating the wrapper class is a piece of cake, and you'll end up with a much more flexible solution that's also more stable.

Please feel free to point out if I've missed anything but IMO DTF is the only way to fly. That should say a lot coming from me and how I dislike so many other things about WiX.
0 Kudos
Not applicable

There's also usability in that the IS method is ( obviously ) supported in the UI, which means more capability for InstallShield to do the work for you. While that might be a non concern for some, I think there are a number of people who do appreciate and enjoy not having to worry about method signatures, etc.

But as far as such concerns as tatooing CLR versions and a vastly inferior API, I think those are subjective.
0 Kudos
Christopher_Pai
Level 16

I've worked in massive scaled product line development environments and when we made the switch from VS2003 to VS2005 I saw many problems with CLR version stickyness ( in both InstallUtil CA's and AppPools ) at the time. CLR 2.0 pretty much took over and it hasn't changed in awhile ( being that 3.0/3.5 aren't changes to the CLR ) but I believe when the next CLR ships it's going to be a good thing to be isolating the process now rather then dealing with defects later.

I suppose you can call it subjective, but after using:

1) C++ / MSI.H MSIQUERY.H
2) InstallSript / ifx.h
3) VBScript / Session Object
4) C# / MSIInterop.cs ( a simple P/Invoke wrapper for the Win32 API )
5) C# / Session Object Interop Library ( difficulat to generate )
6) C# / Pahvant.MSI ( Rich Tompson's class model that encapsulates Win32 API )
7) C# / InstallShield Interop
😎 C# / DTF - Microsoft.Deployment.WindowsInstaller

DTF wins hands down.
0 Kudos