YAUM - Yet Another Update Manager
Re: YAUM - Yet Another Update Manager
Hi highend,
I now tried v0.71 BETA. (Didn't try any other ones before.)
Cool job. Thx for the effort.
I am mostly using XY at work.
At work we have Panda Endpoint Protection (anti-virus).
It says that YAUM.exe is "Infected" respectively is/contains a virus.
No other details given.
I more or less would trust you that this is a false alarm but at work I cannot change the settings of the anti-virus (nor can I really have them changed - in such cases).
P.S.: I am using the installed version of XY so far but the "problem" is YAUM.exe (when I execute it) so it should not have anything to do with XY installed or portable, right?
(I remember that some file connected to Autoit3 has caused a similar warning, at least in the past. I think it had something to do with a hook or so if I remember correctly. Maybe it is similar here?)
Regards
I now tried v0.71 BETA. (Didn't try any other ones before.)
Cool job. Thx for the effort.
I am mostly using XY at work.
At work we have Panda Endpoint Protection (anti-virus).
It says that YAUM.exe is "Infected" respectively is/contains a virus.
No other details given.
I more or less would trust you that this is a false alarm but at work I cannot change the settings of the anti-virus (nor can I really have them changed - in such cases).
P.S.: I am using the installed version of XY so far but the "problem" is YAUM.exe (when I execute it) so it should not have anything to do with XY installed or portable, right?
(I remember that some file connected to Autoit3 has caused a similar warning, at least in the past. I think it had something to do with a hook or so if I remember correctly. Maybe it is similar here?)
Regards
[AHK] redirecting Windows Explorer to XY, [XYS] Mini Tree with open tabs (cur loc expanded, tab folders highlighted), [AHK] customInlineRenameKeys, [AHK] clipboardHelper_and_XYEscToList
Re: YAUM - Yet Another Update Manager
It's a false alarm. AHk / AutoIt programs trigger it sometimes but mostly when they are upx-packed. I don't do that. Maybe you should send it to Panda once it's out of beta.I more or less would trust you that this is a false alarm but at work I cannot change the settings of the anti-virus (nor can I really have them changed - in such cases).
This is a virustotal report on v0.71 BETA:
https://www.virustotal.com/de/file/58bb ... 441262635/
Even that Panda version that they're using over there states that YAUM is clean...
There is an internal difference. YAUM checks if the watched xyplorer.exe is in a path (ProgramFiles / ProgramFiles(x86)) where YAUM needs elevation to be able to copy the update files into. But I doubt that this behavior should trigger an antivirus alertI am using the installed version of XY so far but the "problem" is YAUM.exe (when I execute it) so it should not have anything to do with XY installed or portable, right?
One of my scripts helped you out? Please donate via Paypal
Re: YAUM - Yet Another Update Manager
Interestingly, while working on xypcre, I've noticed the opposite.highend wrote:AHk / AutoIt programs trigger it sometimes but mostly when they are upx-packed. I don't do that.
Detection ratio for a recent UPX-compressed xypcre.exe: 1/56
Detection ratio for a recent non-UPX xypcre.exe: 2/55
Okay, they may not have much difference now, but some older xypcre.exes had DRs of ~1/55 and ~5/55 for upx and non-upx resp.
highend, send upx-compressed yaum to VT, the Detection rate could go down.
Icon Names | Onyx | Undocumented Commands | xypcre
[ this user is asleep ]
[ this user is asleep ]
Re: YAUM - Yet Another Update Manager
Actually, it's going up
3 with unpacked .exe
4 with upx packed .exe
I've never even heard of scanning engines like:
Jiangmin or Zillya...
I'll remove all autoelevation from the source and try it again just to see if it's still "detected"...
Even after removing all autoelevation stuff and WMI calls... the same three engines still claim it as infected.
Can't do anything about that...
3 with unpacked .exe
4 with upx packed .exe
I've never even heard of scanning engines like:
Jiangmin or Zillya...
I'll remove all autoelevation from the source and try it again just to see if it's still "detected"...
Even after removing all autoelevation stuff and WMI calls... the same three engines still claim it as infected.
Can't do anything about that...
One of my scripts helped you out? Please donate via Paypal
Re: YAUM - Yet Another Update Manager
That doesn't matter to the enduser. Send them to a VT analysis page, and the only thing most visitors note is the detection rate, not who detected it.highend wrote:I've never even heard of scanning engines like:
Jiangmin or Zillya...
Icon Names | Onyx | Undocumented Commands | xypcre
[ this user is asleep ]
[ this user is asleep ]
Re: YAUM - Yet Another Update Manager
That may be the case or not, whatever triggers these engines, it's a necessary part of the application and can't be removed.Send them to a VT analysis page, and the only thing most visitors note is the detection rate, not who detected it.
Use this code:
Code: Select all
Gui, New, , test
Gui, Add, Text, x10 y10, test
Gui, Show, w150 h40
Return
GuiClose:
ExitApp
No upx: 3 engines claim it's infected
Upx: 4 engines claim it's infected
An AutoHotkey application that just opens a window, nothing more...
One of my scripts helped you out? Please donate via Paypal
Re: YAUM - Yet Another Update Manager
v0.72 BETA is available
Changed main gui:- Added option: Run always elevated
This will start YAUM with admin permissions (to be able to update e.g. a portable XY that runs with admin rights)
If you switch it on, a red remark pops up, reminding you, that you need to restart YAUM to actually make this setting active
If YAUM was already elevated, ofc no restart is required (and no red remark pops up)
This will allow YAUM to restart non elevated XY instances with user permissions (instead of elevating them, too) in the future.
- The window title will reflect if YAUM is running elevated or unelevated. The old title, if a new (beta) version is available, etc. was removed. That info is visible in the gui...
- The separate download window was removed. The download status is now integrated into the main gui. See the screenshot in the first post...
One of my scripts helped you out? Please donate via Paypal
Re: YAUM - Yet Another Update Manager
Don't know if you can reproduce this:
When working portable, I keep "run in background" OFF, to be able to unplug my stick at any time.
I rather close the dialog, and open it again. Which it fails to do, if I just updated and there is no new update available yet.
What I also get occasionally - mostly when switching Beta-checks ON again after it has been Off, are GUI glitches like this:
When working portable, I keep "run in background" OFF, to be able to unplug my stick at any time.
I rather close the dialog, and open it again. Which it fails to do, if I just updated and there is no new update available yet.
What I also get occasionally - mostly when switching Beta-checks ON again after it has been Off, are GUI glitches like this:
Re: YAUM - Yet Another Update Manager
It doesn't fail. Look at it like this: Your XY version is up to date. Run in background is off.Which it fails to do, if I just updated and there is no new update available yet.
When YAUM starts it looks for an update. There isn't one. No run in background -> Exit
Would it be better to still show the gui if run in background is off and no update is found?
And next question: Run in background = on, no update found, do not show the gui but just switch to background mode? -> Otherwise it wouldn't be possible to let it run in the background right from the start...
Even with v0.72? There were a few of these glitches in versions < v0.7 but I thought I got all of them with the latest one...What I also get occasionally - mostly when switching Beta-checks ON again after it has been Off, are GUI glitches like this:
One of my scripts helped you out? Please donate via Paypal
Re: YAUM - Yet Another Update Manager
Hi highend, if run in the background is set by the user to be off, then if we start YAUM and there is an update to be performed, then simply update XY no message necessary (we can see it happening). If YAUM determines XY is up-to-date then it might be appropriate to provide a message to dismiss (I'm flexible on this though) or a timed message. On the other hand, once the users know that it performs when it needs to and does nothing when it needs to, why bother with a message. While we're on the topic of NOT running in the background, if I execute YAUM why not have a setting that is more like Auto Execute (i.e., why show the interface at all - simply update so the user doesn't even have to click on the "Update now" button - it would be like an Auto Update for users not running it in the background. Seeing the download box would be still appropriate in this case.
On your second question with background on, I would think the user wouldn't need to see the GUI, because he's set it up to be automatic and shouldn't care.
By the way, when running on-demand, are we always better to close as it says to do? Or is it alright to just let YAUM do it? I ask because just now I ran YAUM to get from 15.70.0101 to 15.70.0102 and it didn't do the update - letting YAUM do the closing. XY titlebar still said v15.70.0101 when finished. I could see it downloading though). The dialog box was up for a long time before I had hit "Update now" while I did some other things if that matters. I then ran YAUM again and closed XY this time before hitting Update now and it updated fine.
Thanks and great job.
On your second question with background on, I would think the user wouldn't need to see the GUI, because he's set it up to be automatic and shouldn't care.
By the way, when running on-demand, are we always better to close as it says to do? Or is it alright to just let YAUM do it? I ask because just now I ran YAUM to get from 15.70.0101 to 15.70.0102 and it didn't do the update - letting YAUM do the closing. XY titlebar still said v15.70.0101 when finished. I could see it downloading though). The dialog box was up for a long time before I had hit "Update now" while I did some other things if that matters. I then ran YAUM again and closed XY this time before hitting Update now and it updated fine.
Thanks and great job.
Windows 11, 23H2 Build 22631.3447 at 100% 2560x1440
Re: YAUM - Yet Another Update Manager
I see. Well, to answer your question, imo Yes, give some hint to let the user know the script did indeed do something. Using myself as an example - as always - I run with BG=OFF when I work portable, which is when I am on a foreign system. No telling what might go wrong there. Maybe the exe was blocked or intercepted, maybe the internet access or site was blocked, maybe I didnt click properly on a mouse I am not used to,....highend wrote: It doesn't fail. Look at it like this: Your XY version is up to date. Run in background is off.
When YAUM starts it looks for an update. There isn't one. No run in background -> Exit
Would it be better to still show the gui if run in background is off and no update is found?
Not tried yet. Later, s.th else came up....highend wrote:Even with v0.72? There were a few of these glitches in versions < v0.7 but I thought I got all of them with the latest one...What I also get occasionally - mostly when switching Beta-checks ON again after it has been Off, are GUI glitches like this:
Re: YAUM - Yet Another Update Manager
I don't think that's a good idea. 1. It's always good to see that something happened at all. 2. A lot of people don't want their running XY autoclosed by YAUM (loosing settings, workspace, etc.). Yes, YAUM will close your running XY instance(s) when you hit update now (at least, it will do it when I finished coding the necessary stuff -> it's all about who is elevated, YAUM, any XY instance, etc.).if run in the background is set by the user to be off, then if we start YAUM and there is an update to be performed, then simply update XY no message necessary
In that case I can show the gui anyway. I like it to be rather clean, not annoying the user with different messages to observe / click.If YAUM determines XY is up-to-date then it might be appropriate to provide a message to dismiss
This should imho only be done when no XY instance are running. I'll make a note and sleep a night over it if that makes senseit would be like an Auto Update for users not running it in the background.
It depends if you want to save your current settings in XY or not (or if you have save settings on exit enabled in XY).By the way, when running on-demand, are we always better to close as it says to do? Or is it alright to just let YAUM do it? I ask because just now I ran YAUM to get from 15.70.0101 to 15.70.0102 and it didn't do the update - letting YAUM do the closing.
I now have the necessary pieces of code to let YAUM handle most of the closing stuff (there is only one case left). If it didn't update, was XY elevated at that time? That would explain that behavior.
Ok.I see. Well, to answer your question, imo Yes, give some hint to let the user know the script did indeed do something.
One of my scripts helped you out? Please donate via Paypal
Re: YAUM - Yet Another Update Manager
Obviously I was wishy-washy on an indication of "No update necessary" situation. It is best to have some indication. I wouldn't bother with the Auto Update I mentioned especially if you'd have it set to do so only if XY is not running. I'd typically have XY running all the time anyway. Though some people might find that option handy - they could run YAUM on bootup with run in the background off and have no interface once-so-ever and not worry about having another program running in the background. It may be valuable in that case.
Windows 11, 23H2 Build 22631.3447 at 100% 2560x1440
Re: YAUM - Yet Another Update Manager
Em, no.they could run YAUM on bootup with run in the background off
If run in background is off = it wouldn't go into background mode
One of my scripts helped you out? Please donate via Paypal
Re: YAUM - Yet Another Update Manager
I wasn't talking about running in the background. I'm talking about a scenario where someone simply wants to have YAUM check for updates - once (on demand) - on-bootup - that's it. Check - update - exit - no background running at all. A situation where the user doesn't want it running in the background. Remember we were discussing "potential" reasons(s) to have YAUM run with no interface showing up with Run in the background OFF. I wouldn't use it personally but maybe someone else would.
Windows 11, 23H2 Build 22631.3447 at 100% 2560x1440