ilko
-
Posts
33 -
Joined
-
Last visited
ilko's Achievements
Seeker (1/7)
1
Reputation
-
These UDF are already quite useful, no need to apologize at all. Changing to HANDLE did the trick, thanks a lot.
-
Got it installed. Compiled the last script in post #19, 32 and 64 bits, AutoIt 3.3.10.2. 32 bits binary work as expected, the 64 bits returns empty array... The 64 bits version does the same when run under WinPE environment. Windows is 8.1 x64 Enterprise Eval. Installing AutoIt on this test virtual machine, will get back later when have more results. Any ideas are welcome. Script in post #18 does the same- ok in 32 bit mode, error 6 in 64 bits in _SetupGetLineCount. Edit: It seems in 32 bit mode the handle returned by SetupOpenInfFile is 8 digits, in 64 bits it's 9, maybe helps.
-
6 ERROR_INVALID_HANDLE The handle is invalid. Mind you, I am testing in WinPE environment. Currently installing the same Win8 x64 to test same script in normal environment. 8x64test.zip
-
A bit of help please Got all working fine during WinPE stage of Vista x32, 7 x64 and 8 x32 setup. On Windows 8 x64 (Enterprise Eval) _SetupGetLineCount fails with error 6, "The handle is invalid". _SetupOpenInfFile seems ok, returning different handles for each inf file processed. Script and inf files are all the same. Do you have any hints?
-
Thanks again for all the answers. Got everything I needed working reliably and fast.
-
Got it, thanks. Overlooked the _SetupGetLineText function and its parameters. Does the 32767 characters limit apply to SetupGetLineText WinApi? I can't see such remarks in the msdn article. Edit: Never mind, silly question.
-
Thanks for the quick reply. I am figuring out a way to parse lots of inf files from driverpacks.net. I need an array with HardwareIDs and the corresponding inf filename. Due to their nature, all kind syntaxes and lots of comments are to be expected. Internal IniReadSection fails with some of the files because of the 32767 characters limitation, hence looking for a already made similar function. Ini or Inf, aren't comments or commented out lines to be ignored in either case? Thanks for the WinApi inf functions, I can't see any relevant function for my needs. Am I missing something obvious?
-
Thanks for the UDF, quite useful. A bit of an issue- commented lines, at start of lines (keys and sections) and after values, seem to get in the results when using _IniReadSectionEx and $INI_2DARRAYFIELD. Attached is a zip file with a few of the files where that happens. DPs.zip
-
Quite useful, thanks. It seems _DeviceAPI_GetDeviceRegistryProperty($SPDRP_COMPATIBLEIDS) returns only one of the compatible IDs. Looking at SetupApi.au3 here, which couldn't get going either, there are a few more structures and cases needed, if I get it right. Can someone experienced shed some light? I was trying to go through MSDN documentation without much success. Added: Got SetupApi.au3 from above working as in here: #include <SetupApi.au3> Dim $hDevs, $tDevInfo, $sDeviceID, $devicename[1][2] = [[0]] $hDevs = _SetupDiGetClassDevs($DIGCF_ALLCLASSES) While _SetupDiEnumDeviceInfo($hDevs, $devicename[0][0], $tDevInfo) $devicename[0][0] += 1 ConsoleWrite("----------- Index: " & $devicename[0][0] & " -------------" & @CRLF ) $sDescr = _SetupDiGetDeviceRegistryProperty($hDevs, $tDevInfo, $SPDRP_DEVICEDESC) $sName = _SetupDiGetDeviceRegistryProperty($hDevs, $tDevInfo, $SPDRP_FRIENDLYNAME) $sHWID = _SetupDiGetDeviceRegistryProperty($hDevs, $tDevInfo, $SPDRP_HARDWAREID) $sCHWID = _SetupDiGetDeviceRegistryProperty($hDevs, $tDevInfo, $SPDRP_COMPATIBLEIDS) ConsoleWrite("Description: " & $sDescr & @CRLF) ConsoleWrite("Friendly Name: " & $sName & @CRLF) ConsoleWrite("Hardware IDs: " & @CRLF & $sHWID & @CRLF) ConsoleWrite("Compatible HardwareIDs: " & @CRLF & $sCHWID & @CRLF) ; ConsoleWrite("------------------------" & @CRLF & @CRLF) ReDim $devicename[$devicename[0][0] + 1][2] WEnd _SetupDiDestroyDeviceInfoList($hDevs) It appears that _DeviceAPI_GetDeviceRegistryProperty in DeviceAPI.au3 and $SPDRP_HARDWAREID should be returning some more data, all the HardwareIDs, just like with $SPDRP_COMPATIBLEIDS. Another question, what would be Matching Device ID, as displayed in Device manager details page? I can't see any similar SPDRP_ constant.
-
#Include <WinAPI.au3> _WinAPI_GetLastErrorMessage() $a = FileCopy("D:\flp.img", "H:\boot\bcd", 8) ConsoleWrite($a & @CRLF & _WinAPI_GetLastErrorMessage() & @CRLF) If a file H:boot already exists, FileCopy fails with "The directory name is invalid.", the directory h:boot is not created and surely the file is not copied. If the file h:boot is renamed or deleted, everything goes fine. Is this expected behaviour or a bug, or I am missing something obvious? Why a file with the same name as the folder which has to be created exists prevents FileCopy from creating that folder and copying the file? FileCopy("D:\flp.img", "H:\boot\" This fails the same way. In addition, is it correct to use a file as destination? Documentation is not 100% clear, and it seems to work. Using AutoIt 3.3.6.1. Edit: Ahh, never mind, Windows.... Explorer also won't let me create a directory "boot" if a file with the same name already exists in that destination, Windows 7 x64.
-
Has anyone gotten this UDF to work with ISO files? I am trying to extract an ISO file, but it fails. The same syntax works fine with zip file.
-
Syed23 reacted to a post in a topic:
_LargeFileCopy UDF
-
Nope. Combine all parameters needed in a single BitOR- BitOR(1, 2, 8, 128, 512) or whatever you need inside.
-
@Sayed23 Use the appropriate flag(s): ; #FUNCTION# ==================================================================================================== ; Name...........: _LargeFileCopy ; Description....: Copy large files in such a way as to keep AutoIt GUIs responsive ; Syntax.........: _LargeFileCopy($sSrc, $sDest[, $iFlags = 0[, $iToRead = 2097152[, $iAlg = $CALG_MD5[, $sFunction = ""[, $vUserVar = Default]]]]]) ; Parameters.....: $sSrc - Source file name ; $sDest - Destination: may be a file name or directory ; $iFlags - [Optional] Combine flags with BitOR ; | 1 - Overwrite existing file ; | 2 - Create destination directory structure ; | 4 - Flush the destination file buffer before returning ; | 8 - Verify source and destination are identical via bit by bit comparison ; | 16 - Verify source and destination are identical via MD5 hash ; | 32 - Verify source and destination file size only ; | 64 - Copy source file attributes (NOT including Compression or Encryption) ; | 128 - Copy source file Creation time ; | 256 - Copy source file Last Accessed time ; | 512 - Copy source file Modified time ; |1024 - Copy source file Security Descriptors and Ownership ; |2048 - Copy source compression state ; |4096 - Copy source encryption state
-
First off- thanks for this great UDF. I've tested and used it only with file copy to USB sticks, here are some results you may find interesting. Legend: LFC 0.25, XP , 379.41 LFC- LargeFileCopy buffered 0.25- buffer used for LFC- _LargeFileCopy($src, $dest, BitOR(1, 2, 8, 128, 512), $buffer * 1024 * 1024, $CALG_MD5) 379.41- seconds to finish XP- I386 folder from XP SP3 Setup CD, being copied from the internal hard disk, 5878 small files, 375MB total. ISO- two ISO files, 414MB and 495MB FileCopy- AutoIt internal FileCopy function WFileCopy- Windows xcopy - Windows xcopy with /q and /h switches. Xcopy and LFC unbuffered took a lot more time so weren't tested at all. YCopy- Yashied's Tested in FAT16, FAT32, NTFS with a fast USB 2.0 stick- A and quite slow one-B, under XP SP3 and 7 x64, tests were repeated several times with format before each test, default cluster size for 4GB partition, AV turned off. A, under XP A, under Windows 7 B, under Windows 7 Did not have patience to repeat the test with the slow stick under XP, but resluts were quite informative for me- LFC flies with small files when the proper buffer is used. For large files, above say 100-200MB I couldn't get it not the freeze the GUI- it does not freeze during copying, but once finished, until windows file system buffer/cache is emptied, it gets frozen. For files above, say 500MB it's quite noticable, can't recall if optimize for performace/quick removal policy helped or not, but wasn't a path to take anyway. Ended up using copy.exe and ProcessGetStats, like As a side note- _LFC_GetDiskClusterSize function seems to need a correction, return should be $aRet[3]*$aRet[2], BytesPerSector*SectorsPerCluster, unless you had other intentions.
-
Sort a multi-dimensional array with multiple sort columns.
ilko replied to Thopaga's topic in AutoIt Example Scripts
Very useful, thanks a lot for sharing it!
