Spiff59

This thread contains many different versions, so when you say you use "this function" it's hard to know what you're running. Whichever you'd chosen, you were unlucky as most in this thread support UNC names. Try the 65-liner in post #252.

Thank you. I truly will look into those. I had some sort of sandbox software set up years ago and it was a pain-in-the-rear. I recall extra drive partitions, multi-boot .ini files, and a lot of rebooting during use. Hopefully the more modern ones don't have such requirements. Is there any sort of data stored in this executable that would be helpful in identifying the author? Any secret bits of info tucked in here or there? Am embedded IP, MAC Address, Hard drive serial number, etc? I guess if a dev told me, it wouldn't be secret anymore Neither PE Explorer nor WinHex found any "Kilroy was here" strings left by the author.

This morning, I'm off searching far and wide for a specific application... And I'm starting to jump into sites with Chinese and Arabic fonts, and sites with .pl and .ru suffixes. I'm know I'm tempting fate. I do have my "panic button" next to the clock that switches me to a basic startup profile (via msconfig), launches rkill.exe, and disables the internet. Half the time I'm able to clean the garbage off without a reboot. Some of the ransomware infects faster than my guards go up, but my default user account is not an administrator, and coming back in as Administrator has worked with all of the fake FBI crap. Worst case scenario, I just pull the drive and hang it off another PC as the D: drive and give it a cleaning. Anyway, I was loading some site, there's a freeze, then boom, Firefox windows start popping up like crazy. I killed the whole browser group, disabled my Local Area Connection and started looking around. Looking at running processes "winvnc86.exe" has red flags all over it as I've become very familiar with what belongs in the process list. I killed winvnc86 and things seeming safe enabled my connection, , started updating combofix and malwarebytes to their latest versions and then googled the winvnc86 filename. I clicked on the first few relevant sites to open in separate tabs and then my pc slowed, I got redirected, popups started again. I locked up and ran the cleaning programs. The popups were due to a couple executables stuck in my "user/local settings/temp" folder, and my 14KB svchost.exe had blossomed to 300KB. It's the other virus that caught my eye, a fairly new variant I guess. It's the one with the winvnc86.exe process, and it had downloaded 3 files to my system32 folder and was getting me setup to mine for bitcoin or litecoin. What I found interesting was that the driver/installer for it all, that had been parked in my "startup" folder, was a bound Autoit 3.3.8.1 executable, 571KB in size, called initsrv.exe. It's actions are well-described here: http://www.tgsoft.it/english/news_archivio_eng.asp?id=562 I found it a wierd mix of both shock and amusement that something malicious, with such an origin, would ever find it's way to my desktop.

You could cheat. I was on a kick a couple years ago offering up some _Arraysearch() replacements that used Assign(), IsDeclared() and Eval() and were blazingly fast. I'm sure other have written them too, but about the first 6 results of an advanced search on "_Arraysearch" with me as the author will provide you with a few examples. I say cheat because, although it works like magic, it's not the intended use of those commands, and using them that way makes me want to hide from anyone I see who is carrying anything even vaguely resembling a "Standards Manual".

I'm finding users adjusting the default screen DPI setting far more often in Windows 7 than I ever experienced with Windows XP. Perhaps the setting is now more prominently displayed or easily found than when is was in the advanced section of the settings tab of the display options window. Most commercial applications seem to adapt to the DPI value without a glitch, but Autoit only partially conforms to this system-wide setting. The fonts within controls are affected, yet the overall control dimensions are not. The result are labels, buttons, etc, with txt that is truncated or unreadable. Some special controls or API functions in Autoit, like calendar, are also affected by the DPI setting. I've overridden non-default DPI settings by calling this at the top of programs: Func GetDPI_Ratio() Local $hWnd = 0 Local $hDC = DllCall("user32.dll", "long", "GetDC", "long", $hWnd) Local $aRet = DllCall("gdi32.dll", "long", "GetDeviceCaps", "long", $hDC[0], "long", 90) $hDC = DllCall("user32.dll", "long", "ReleaseDC", "long", $hWnd, "long", $hDC) If $aRet[0] = 0 Then $aRet[0] = 96 Return $aRet[0] / 96 EndFunc It returns an $iDPI_Ratio global such as 1 or 1.25. I then replace all calls to GUISetFont() and GUICtrlSetFont() with calls to user functions like GUISetFont_DPI() and GUICtrlSetFont_DPI() which apply the $iDPI_Ratio variable as a divisor to the font size parameter like this: Func GUISetFont_DPI($isize, $iweight = "", $iattribute = "", $sfontname = "") GUISetFont($isize / $iDPI_Ratio, $iweight, $iattribute, $sfontname) EndFunc I'm still left with a few uncorrected issues like calendar controls. I considered a bugtracker to request an extra parm for GUISetFont() and GUICtrlSetFont(), that would act as a DPI divisor and default to 1. That would greatly simplify programatically suppressing a non-standard DPI setting. Then I wonder if perhaps the goal should be to move in the opposite direction... that of making Autoit fully DPI-aware? It appears the available values for the DPI setting are: .75 1.00 (default) 1.25 1.50 2.00

I'd thought those changes had been implemented. When the AutoIt beta 17 forced me to rename _ExcelBookOpen() to _Excel_BookOpen(), I was surprised to find the read-only functionality missing. It must be an early Alpha version of the rewrite that's bundled in Beta 17? I assume that soon a Beta will contain a newer version of the rewrite? I could cheat and go google up an answer to your question. I do know that 3 years ago, when I first modded a personal version of the function to report locked files, that I also did some cleanup and had decided there was something about hidden worksheets that justified leaving that code intact. I just can't recall what that was

While 1 $reg2 = RegEnumKey("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\", 1) If @error Then ExitLoop $del = RegDelete("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\" & $reg2) Wend I guess that would be the simplest? I am still confused at the results RegEnumVal give me in the post #2 example above...

I thought for a moment that relying upon @error = 0 might be a mistake as it's not documented anywhere that a 0 is returned. But it appears to be much less fun than that... are we missing a comma between the RegDelete() parameters? Edit: There's more to this than first meets the eye... Edit2: I have the following 4 keys beneath the "972" key you reference: {718BB738-AA76-4BE1-AB9B-C4DA931A4B4D} {9B79FBA7-7082-4276-80E8-D7C8F3C732B2} {F4746EE5-DA79-4CEB-92D6-AB2E3F2A8E37} Descriptions When I run the following, I seem to get the results I'd expect out of RegEnumKey, but not RegEnumVal... #RequireAdmin Local $key = "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\" Local $I, $reg2, $del, $err1, $err2 For $I = 1 To 5 $reg1 = RegEnumKey($key, $I) $err1 = StringRight(" " & @error, 2) $reg2 = RegEnumVal($key, $I) $err2 = StringRight(" " & @error, 2) ConsoleWrite("$I = " & $I & @CRLF & " @error = " & $err1 & " key = " & $reg1 & @CRLF & " @error = " & $err2 & " val = " & $reg2 & @CRLF) ; $del = RegDelete($key" & $reg1) Next The $I=2 iteration for subkey {718BB738-AA76-4BE1-AB9B-C4DA931A4B4D} returns a val of "Class" and @error = 0. Iterations 3 and 4 for {9B79FBA7-7082-4276-80E8-D7C8F3C732B2} and {F4746EE5-DA79-4CEB-92D6-AB2E3F2A8E37} return no val string and both receive an @error = -1. Yet the structure for all 3 keys appears to be identical. Sorry I wasn't of any help.

For a few years anytime I'd install a new version of AutoIt (Prod or Beta) I'd immediately go delete three functions from the Excel UDF: _ExcelBookOpen(), _ExcelSheetAddNew(), and _ExcelReadSheetToArray(). Bugtracker #2199 fixed the issue with _ExcelSheetAddNew(). Bugtracker #2219 had the rewrite of _ExcelReadSheetToArray(). Both were implemented in Beta version 3.3.9.5. I'm now left with only having to replace a single function, the standard _ExcelBookOpen(), with a custom version because it still has no logic to report whether a worksheet that was requested to be opened in read-write mode, was instead opened as read-only. There was some discussion in this thread about _ExcelBookOpen around posts #7 and #43. Shortly after post #43 I modified the function again to use the .Readonly property instead of the FileOpen/FileClose method and have been using the following ever since: Global Const $xlSheetVisible = -1 _ExcelBookOpen2("\\Server1\Directory1\test.xls", True, False) If @error Then MsgBox(0,"","@Error = " & @error) ;----------------------------------------------------------------------------------------------------------------------------------- Func _ExcelBookOpen2($sFilePath, $fVisible = True, $fReadOnly = False, $sPassword = "", $sWritePassword = "") If Not FileExists($sFilePath) Then Return SetError(2, 0, 0) $fVisible = ($fVisible > 0) $fReadOnly = ($fReadOnly > 0) Local $oExcel = ObjCreate("Excel.Application") If Not IsObj($oExcel) Then Return SetError(1, 0, 0) Local $oWorkbook = $oExcel.WorkBooks.Open($sFilePath, Default, $fReadOnly, Default, $sPassword, $sWritePassword) If (Not $fReadOnly) And $oWorkbook.Readonly Then $oExcel.Quit Return SetError(3, 0, 0) EndIf $oExcel.Visible = $fVisible ; Select the first visible worksheet. For $i = 1 To $oWorkbook.Sheets.Count If $oWorkbook.Sheets($i).Visible = $xlSheetVisible Then $oWorkbook.Sheets($i).Select() ExitLoop EndIf Next Return $oExcel EndFunc ;==>_ExcelBookOpen It puts the "@Error = 2 - File not found" test where it ought to be (before launching Excel), simplifies the parameter edits, eliminates a flock of truly unnecessaary compound If/Then statements, and adds an "@Error = 3 - Workbook in use" test to report when a workbook is not available for update.

Hello Fred, The $ACCESS_SYSTEM_SECURITY constant is now defined in the Beta version of SecurityConstants.au3. To avoid an error, at some point, it will need to be deleted from Permissions.au3. Thanks. Edit: Fred hasn't been online since the end of May, so y'all may be wantin' to individually apply this fix.

Doh! Pardon me, I'd forgotten Permissions.au3 was from the Examples forum and not a standard UDF. I'll delete the redundant define from Permissions.au3 and post a msg over in FredAI's thread suggesting he do the same.

There's a bug in the Beta presently regarding the $ACCESS_SYSTEM_SECURITY constant. Previously, it was defined only in Permissions.au3. Now (at least as of Beta 17), it is defined in both Permissions.au3 and SecurityConstants.au3. SecurityConstants.au3 is, and has been, a "sub-include" within the Permissions.au3 include. It's resulting in a redefined constant error. Thanks.

No, I did not. I've never installed other than the main AutoIt download (prod or beta) and the SciTE4Autoit download. How many of those do I need to install separately? Thanks.

I realized my SciTE was out-of-date so updated it to 3.3.0. Nothing seems to compile in Beta (16) anymore. I'm specifying to run Obfuscator with just the /so parameter. Obfuscator does not run and I get this before it dies: Aut2Exe Error Line 0 (File "<path>\<file>_Obfuscated.au3"): Error: Error opening the file. If I create an empty <file>_obfuscated.au3 file in advance, it will get populated and the .exe created. I also notice these from Autoit3Wrapper 2.1.2.9 when i run compile from within SciTE: -> Skipping AU3check: Current version doesn't support the AutoIt3 v 3.3.9.5+ syntax. -> Skipping Obfuscator: Current version doesn't support the AutoIt3 v 3.3.9.5+ syntax. I'm thinking the easiest route might be to just revert to the older SciTE and let such things be resolved in time.

It appears we've fleshed out the details that trancexx didn't elaborate on, and show post 5 hit the nail on the head. Edit: Some of the above are "compiler" warnings, and some execution errors... Think someone will fix so that correct message shows on correct variable without creating a Bugtracker?