View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001607||SUMo||Bug||public||2012-06-19 08:11||2012-08-08 23:49|
|Platform||Desktop||OS||Windows Vista 64|
|Fixed in Version||3.4|
|Summary||0001607: General detection troubles with parallel 32/64bit application, with mutual exclusion|
|Description||It seems previously reported issues with dettection of parallel 32/64bit application are more general, so does mutual exclusion of items in case of manual addition.|
|Steps To Reproduce||Install on 64bit Windows both 32 and 64 bit flavours of application.|
Check if both are listed after scan.
If not, try manually add the other.
Check if the new one replaces the original one items.
This time verified for FFDShow http://ffdshow-tryout.sourceforge.net/
and recently reported also for VirtualDub via forum
|Additional Information||Related |
0001582 SUMO does not detect 64bit Adobe Flash Player plugins
0001584 SUMO does not detect both 32bit + 64bit java instalation - mutualy excluding items
|Tags||No tags attached.|
even if the both 64 and 32 files look internally the same ( same version, same internal name ),
it should be taken as different items, if they are from 32b and 64b Program files folders, or from system32 and sysWOW64 folders.
||This is the right method.|
I don't think this the right method here, Kyle. It's totally unreliable.
AFAIK, those special folders' usage is only controlled by MS development guidelines, not by any technical means on the OS level. There're lots of exceptions in reality for various reasons. Moreover, this method doesn't cover apps installed in other locations, e.g. in user profiles or any other arbitrary folder (and manually added to SUMo list).
We should rather rely on direct info from PE headers (PEType or MachineType tags). There're some well-known exceptions for this approach, too. But afaik, those cases are irrelevant for the purpose of SUMo utility, so it's safe to use here.
I would also suggest to explicitly show bit-size/platform info in the Version and Update columns, e.g.:
"(32-bit) 220.127.116.116" / "(64-bit) 1.0.2.03" or
"(x86) 18.104.22.1686" / "(x64) 1.0.2.03"
"Update available (32-bit) 22.214.171.1246" / "Update available (64-bit) 1.0.2.03" or
"Update available (x86) 126.96.36.1996" / "Update available (x64) 1.0.2.03"
For Adobe Flash for IE and FF, there is a simple workaround as the file have 32_ or 64_ in their names.
For Java, i may use the x64 property of the OS itself ?
For others i wouldn't differentiate 32/64 bits.
||Btw, would you please attach the file you posted on RapidShare (unable to get it) ?|
>> For others i wouldn't differentiate 32/64 bits.
Why so, Kyle? Aren't you interested in implementing a universal approach? Is it that hard to get one extra field when scanning?
There're much more valid cases when ppl need to maintain both 32- and 64-bit versions nowadays, especially in testing, development, administration or tech support environments. This issue aren't going away, it's only becoming more and more widespread as time goes forward.
I'd love this for sure... but what's the most robust method to do this ?
I'll try to implement this using the
Program files -> 64 Bits
Program files (x86) -> 32 bits
method. We'll see if it is enougth.
>> what's the most robust method to do this ?
I'm sorry, but haven't you read my first post here?
PEType = PE32 --> 32 bit app
PEType = PE32+ --> 64 bit app
It's that simple. Don't know if Delfi 7 default libs expose this info.
>> We'll see if it is enougth.
Sure it's not. First things that come to my mind:
1) some apps install into User Profile folders, not in the system-wide Program Files folders (e.g. Google Chrome);
2) other apps install their _both_ flavors (32 & 64-bit) under "Program Files (x86)" (e.g. TeamViewer, AC3Filter, Haali Media Splitter, Dritek Launch Manager);
3) portable apps and tools can live almost anywhere and mostly never under standard Program Files.
I suppose you wanted this file....
Concerning java, it cannot be taken by OS type,
as both instances can be needed and are installed independently.
E.g. for java applications is used java64 for better performance
and sometimes larger address space.
I use one java app using intentionally 4-8 GB of RAM.
For Firefox32 is needed java32.
Looks like SUMo doesn't currently take into account file names when mapping to versions, only Product/Company combo, am I correct?
Not sure if the link works properly, so enother attempt
- File names are only used in very specific case for tiltering / rewriting.
- "I'm sorry, but haven't you read my first post here?"
PEType = PE32 --> 32 bit app, PE32+ --> 64 bit app.
Sorry , i read this too fast "There're some well-known exceptions for this approach, too. But afaik, those cases are irrelevant for the purpose of SUMo utility, so it's safe to use here.".
This is obviously the most robust and appropriate way to do it.
That's what i'll do !
Thank you !
Just prototyped it : it works !
It's so easy to grab PEType :)
||I told you it was peace of cake ;) That's why I wondered why you chose to mess around with special folders in the first place...|
||... because i was absolutely not aware of the PEType trick :)|
>> I would also suggest to explicitly show bit-size/platform info in the Version and Update columns, e.g.:
And how about this suggestion?
I prefer to show only the relevant update. If 64bits exe is loaded, then "(64 bits)" is added to its name and 64bit update is displayed.
Otherwise, only 32 bits info are used.
Implementation is done and tested. Let's wait for release for you to test it and comment :)
|2012-06-19 08:11||poutnikg||New Issue|
|2012-06-19 08:39||poutnikg||Note Added: 0000888|
|2012-06-19 21:04||Kyle_Katarn||Assigned To||=> Kyle_Katarn|
|2012-06-19 21:04||Kyle_Katarn||Status||new => acknowledged|
|2012-08-02 23:04||Kyle_Katarn||Note Added: 0000999|
|2012-08-03 20:56||bytehead||Note Added: 0001000|
|2012-08-03 20:57||bytehead||Note Edited: 0001000||View Revisions|
|2012-08-03 21:05||bytehead||Note Edited: 0001000||View Revisions|
|2012-08-03 21:05||bytehead||Note Edited: 0001000||View Revisions|
|2012-08-03 21:24||bytehead||Relationship added||parent of 0001650|
|2012-08-03 21:24||bytehead||Relationship deleted||parent of 0001650|
|2012-08-03 21:25||bytehead||Relationship added||related to 0001650|
|2012-08-03 22:15||Kyle_Katarn||Note Added: 0001001|
|2012-08-03 22:16||Kyle_Katarn||Note Added: 0001002|
|2012-08-03 22:32||bytehead||Note Added: 0001004|
|2012-08-03 22:39||Kyle_Katarn||Note Added: 0001005|
|2012-08-03 23:07||bytehead||Note Added: 0001006|
|2012-08-03 23:09||bytehead||Note Edited: 0001006||View Revisions|
|2012-08-04 00:50||poutnikg||Note Added: 0001007|
|2012-08-04 02:21||bytehead||Note Edited: 0001006||View Revisions|
|2012-08-04 02:44||bytehead||Note Added: 0001008|
|2012-08-04 09:39||poutnikg||Note Added: 0001012|
|2012-08-04 10:48||poutnikg||Note Edited: 0001007||View Revisions|
|2012-08-04 14:06||Kyle_Katarn||Note Added: 0001017|
|2012-08-04 14:40||Kyle_Katarn||Note Added: 0001022|
|2012-08-04 14:48||bytehead||Note Added: 0001024|
|2012-08-04 14:50||Kyle_Katarn||Note Added: 0001026|
|2012-08-04 14:52||bytehead||Note Added: 0001027|
|2012-08-04 15:14||Kyle_Katarn||Note Added: 0001028|
|2012-08-04 15:14||Kyle_Katarn||Status||acknowledged => resolved|
|2012-08-04 15:14||Kyle_Katarn||Fixed in Version||=> 3.4|
|2012-08-04 15:14||Kyle_Katarn||Resolution||open => fixed|
|2012-08-08 23:49||bytehead||Relationship added||child of 0001668|