|
Thank you Dave.
However I'd rather to use WMI, because I want to get this information from remote computers in my network. Also, my little application is actually a JavaScript code, not .NET .
|
|
|
|
|
Over the network every second?? You're asking a bit much. There is no way to speed up the results of a WMI query. It takes as long as it takes.
As for being Java code, you should have specified that in the original post. The quality of the answer you get is directly dictated by the quality of the question.
|
|
|
|
|
There is a WMI class which represents the Processor performance counter object. See Win32_PerfFormattedData_PerfOS_Processor, specifically the PercentProcessorTime property. It may be that this is faster to retrieve than the other value.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Dave: I agree I should said that it is a JavaScript in my first post.
Mike: Thank you - that was exactly what I was looking for.
|
|
|
|
|
Hi guys,
On a workgroup environment, if you interactively login (runas command) with your admin user under your regular user session (Power User), and you kick yourself out from the Administrators group. How can you get back to be an admin on that PC? 
Is it possible to revert back this action?
Thanks,
...neualex
|
|
|
|
|
Another Admin equivilent account has to add you back to the Administrators group. There is no "undo"...
|
|
|
|
|
That's where the problem lies, there is no another admin account.
I guess I will have to run the File and Setting Transfer Wizard and reinstall WinXP 
|
|
|
|
|
There is: the built-in Administrator account. If you have changed all other users to standard users, the built-in Administrator account will appear in the Welcome screen. By default it has no password.
If it does not appear on the Welcome screen, you can press Ctrl+Alt+Del twice to get the old login dialog up, where you can log on as Administrator.
Note that in Windows XP accounts without passwords cannot log on remotely, so this configuration is actually probably more secure than an administrative account with a weak password.
Personally I use this configuration - my own account is a standard user, and the Administrator account is enabled. I use that account for all administrative actions and use the limited account for day-to-day tasks. There are a number of XP features that don't work properly (e.g. Power Options control panel) where you have to use MakeMeAdmin[^] to temporarily elevate your standard account to an administrator.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Mike,
Thanks for the prompt reply.
Even the built-in admin account is kicked out from the Administrators group.
In other words, there is no account in the Local Administrators group on this box 
|
|
|
|
|
neualex wrote: Even the built-in admin account is kicked out from the Administrators group.
That's impossible. You cannot remove the built-in Admin account from the Administrators group.
|
|
|
|
|
Dave,
You are right, the administrator account is not removed from the Administrators group.
The problem is that the account is disabled , and there is no other account with admin rights to enable it. Power user cannot do it.
Is there still hope?
|
|
|
|
|
|
Dave,
Thanks for the post.
However, let me remind you that only one admin account exists on this XP box, and it is disabled.
The post explains how I can reset the password, but not how to enable it back.
If I miss something, please let me know.
Thanks again,
neualex 
|
|
|
|
|
I know. There is a CD image on that site. Burn the CD, boot the machine on it (it's a Linux boot!) and it'll let you reset the password AND re-enable the account.
|
|
|
|
|
Hi folks. I'm hoping someone can tell me the metric Windows Installer uses to determine if an existing instance of an application is installed on a system, because I changed a bunch of settings for my setup project and now when it's installed over an existing copy, I get two entries in the Add/Remove Programs control panel. It was working before.
Some notes:
-Both apps install to the same directory and include 99% the same file names.
-Both have the same version as encoded to the installer (diff assembly versions, mind).
-The ProductCode is changed for every update, but I've been doing this all along with no probs.
What can I do to prevent this duplicate entry from occurring? It's a real problem because they cannot both be "uninstalled" as they're using the same files!
Thanks in advance,
Logan
{o,o}.oO( Did somebody say “mouse”? )
|)””’)
-”-”-
|
|
|
|
|
They should both be able to be uninstalled. Windows Installer reference counts installed components and does not remove files until they are no longer referenced by any installed product. It tracks installed components on a per-directory basis - it can cope with the same component being installed in multiple directories and removes each separate install location when that location is no longer referenced. (It doesn't actually count - it records which products have installed which components in which directory).
Note that file versioning rules exist. If a file has a version number in its resources (typically only EXEs and DLLs), the file with the greater version number wins. If only the new file has a version number, that will overwrite an existing file without a version. If neither file has a version number, the incoming file always overwrites the existing one, unless it has been edited (its modified timestamp is different from its creation timestamp - Windows Installer sets the creation timestamp and modified timestamp the same when installing the file). Registry entries are always overwritten. The net effect is that when you uninstall the new product, the newer files are actually left behind, you are not prompted to reinstall or repair the old one.
You can get into trouble if you have multiple components which install the same file to the same location, because Windows Installer will no longer have accurate reference counts. See Rob Mensching's (creator of WiX) blog post "Component Rules 101"[^] for more on this. However, if you're merely modifying the same installer project, Visual Studio will keep the same component identifier GUIDs for the same files (this may not be correct, if your resources are not in fact compatible across multiple versions, and VS has no way to allow you to change a GUID, except by removing and replacing the file).
Changing the Product Code is absolutely correct for a major upgrade. Visual Studio does not offer much assistance for minor upgrades, so you should really stick to major upgrades. You should always change the Package Code for any new build of your package.
Windows Installer detects families of products using the Upgrade Code. This GUID should be kept the same across all versions of your product until you want to break the family association. Windows Installer itself supports detecting any number of Upgrade Codes, optionally removing them before or after installing the new product, but Visual Studio does not allow them to be specified, specifying only the UpgradeCode from the current package.
In VS, you control what happens using the RemovePreviousVersions and DetectNewerInstalledVersion properties. You cannot choose when the RemoveExistingProducts action is scheduled; it's always scheduled after InstallInitialize. That means that if the new installer fails, the old product is reinstalled, and the old components are removed before adding the new ones. This is a pretty safe choice.
You've probably either changed the UpgradeCode or one of those two properties. I would leave them both set to True unless you really want side-by-side installations.
Windows Installer is much more complicated than it initially seems and in my opinion, has no business in a dumbed-down developer tool like Visual Studio. At least, not in this dumbed-down form. If you're going to use it I strongly recommend getting the book "The Definitive Guide to Windows Installer" by Phil Wilson, from Apress.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Wow thanks a ton for the detailed response. Based on your description, I am betting it's the UpgradeCode, since I do remember changing that. I was under the impression that ProductCode was logically superior to UpgradeCode (based simply on their names), thinking that changing UpgradeCode would have no effect if I was also changing ProductCode. Apparently this is not correct at all! They should have called UpgradeCode FamilyCode or something to that effect.
Now I have to figure out what the previous UpgradeCode was so I can restore it! :P
Also I believe I was having trouble uninstalling both due to the fact that both "products" (really just one, hence the problem) use installer services to perform uninstall actions.
Windows Installer sure is complicated. If I decide to continue working with it I will most definitely check out that book on your recommendation. That said, however, are there any other third-party installation tools you would recommend over Windows Installer?
Aha, found the UpgradeCode using Orca to look into my older installer.
Thanks for the reply. This has undoubtedly saved me a lot of headaches.
{o,o}.oO( Did somebody say “mouse”? )
|)””’)
-”-”-
|
|
|
|
|
What linux commands which use to get file size(ContentLength) of target url such as "http://www.xxx.com/pic.zip"?
thank
|
|
|
|
|
Try asking in a linux forum.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Anyone using Powershell yet?
Like it?
“If we are all in agreement on the decision - then I propose we postpone further discussion of this matter until our next meeting to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.”-Alfred P. Sloan
|
|
|
|
|
|
Yes, "I be meaning that". You use it? Like it?
“If we are all in agreement on the decision - then I propose we postpone further discussion of this matter until our next meeting to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.”-Alfred P. Sloan
|
|
|
|
|
My contact in Microsoft Exchange Support calls it 'PowerHell'.
This may however simply be that some operations that could be done through the GUI in Exchange Server 2003 can only be done through cmdlets in 2007. Basically Microsoft rewrote the whole management interface for 2007 in .NET 2.0 in order to use PowerShell and Microsoft Management Console 3.0 (which allows .NET snap-ins without COM Interop), but all of those technologies were delayed and they didn't finish the GUI bits in time for RTM.
Apparently more GUI features are coming in SP1. Still too soon for us, though - Exchange Server 2007 requires x64 and we can't afford to dedicate a box solely to Exchange, so our newly installed servers (about a month old) run the 32-bit OS and Exchange Server 2003.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Hi
Can any one explain me with example
Regards,
Sivaprasad
|
|
|
|
|
Application Programming Interface...
This is a better explanation than any I could do for you[^]
“If we are all in agreement on the decision - then I propose we postpone further discussion of this matter until our next meeting to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.”-Alfred P. Sloan
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
