This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Hardware information
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 04, 2008
09:30 AM
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!
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!
(15) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 04, 2008
11:11 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 04, 2008
11:24 AM
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!
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!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 07, 2008
10:55 AM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 07, 2008
02:37 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 09, 2008
12:00 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 09, 2008
09:08 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 13, 2008
08:29 AM
Thanks a lot, Dan!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 17, 2008
05:48 AM
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!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 17, 2008
07:08 AM
That's an old link. Read this one:
http://robmensching.com/blog/archive/2008/05/16/Deployment-Tools-Foundation-joins-the-WiX-toolset.aspx
Also you can go to my blog and do a search for DTF which will return various articles I've written over the years:
(These two are interesting... I had a poll where 75% of my readers said they want to use managed code custom actions and a couple weeks later WiX released DTF which had been kept internal and secret for years. )
http://blog.deploymentengineering.com/2008/04/new-poll-manged-code-custom-actions.html
http://blog.deploymentengineering.com/2008/04/you-cant-escape-net.html
(Interesting timeline)
http://blog.deploymentengineering.com/2008/05/price-of-ideology-and-great-new-hope.html
http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
http://blog.deploymentengineering.com/2008/05/data-driven-cas-made-easy-with-dtf.html
http://blog.deploymentengineering.com/2008/05/how-dtf-is-going-to-help-me-become.html
http://blog.deploymentengineering.com/2008/07/reasons-dtf-is-better.html
http://blog.deploymentengineering.com/2008/08/dont-believe-everything-you-read.html
http://robmensching.com/blog/archive/2008/05/16/Deployment-Tools-Foundation-joins-the-WiX-toolset.aspx
Also you can go to my blog and do a search for DTF which will return various articles I've written over the years:
(These two are interesting... I had a poll where 75% of my readers said they want to use managed code custom actions and a couple weeks later WiX released DTF which had been kept internal and secret for years. )
http://blog.deploymentengineering.com/2008/04/new-poll-manged-code-custom-actions.html
http://blog.deploymentengineering.com/2008/04/you-cant-escape-net.html
(Interesting timeline)
http://blog.deploymentengineering.com/2008/05/price-of-ideology-and-great-new-hope.html
http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
http://blog.deploymentengineering.com/2008/05/data-driven-cas-made-easy-with-dtf.html
http://blog.deploymentengineering.com/2008/05/how-dtf-is-going-to-help-me-become.html
http://blog.deploymentengineering.com/2008/07/reasons-dtf-is-better.html
http://blog.deploymentengineering.com/2008/08/dont-believe-everything-you-read.html
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 21, 2008
02:14 PM
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?
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 21, 2008
02:36 PM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 21, 2008
03:54 PM
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.
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.
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 24, 2008
01:08 PM
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.
But as far as such concerns as tatooing CLR versions and a vastly inferior API, I think those are subjective.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 24, 2008
01:55 PM
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.
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.