Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Calling Windows API

 [1/8] from: patrick::philipot::laposte::net at: 13-Dec-2004 13:40


Hello Rebol-List, I've got a problem when calling windows API. Here is an example : ; GetVolumeInformationA is returning the disk system (FAT32 or NTFS) ; in a buffer (FileSystemNameBuffer)that I have declared ; FileSystemNameBuffer: "YYYYYYYYYYYYYYYYYYY" kernel32.dll: load/library %/C/WINDOWS/system32/kernel32.dll GetVolumeInfo: make routine! [ disk [string!] lpVolumeNameBuffer [string!] size [integer!] lpVolumeSerialNumber [integer!] lpMaximumComponentLength [integer!] lpFileSystemFlags [integer!] lpFileSystemNameBuffer [string!] size2 [integer!] return: [integer!] ] kernel32.dll "GetVolumeInformationA" VolumeNameBuffer: "XXXXXXXXXXXXXXXXXXXX" FileSystemNameBuffer: "YYYYYYYYYYYYYYYYYYY" GetVolumeInfo "C:\" VolumeNameBuffer 20 0 0 0 FileSystemNameBuffer 20 ?? FileSystemNameBuffer The problem is that I don't get a clean buffer but
>> ?? FileSystemNameBuffer
FileSystemNameBuffer: "FAT32^@YYYYYYYYYYYYY" == "FAT32^@YYYYYYYYYYYYY" What do I have to do to get only "FAT32" ? -- Regards, Patrick

 [2/8] from: gabriele:colellachiara at: 13-Dec-2004 14:00


Hi Patrick, On Monday, December 13, 2004, 1:40:11 PM, you wrote: PP> What do I have to do to get only "FAT32" ? copy/part buffer find buffer #"^@" Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [3/8] from: petr:krenzelok:trz:cz at: 13-Dec-2004 14:18


Patrick Philipot wrote:
>Hello Rebol-List, >I've got a problem when calling windows API.
<<quoted lines omitted: 24>>
>FileSystemNameBuffer: "FAT32^@YYYYYYYYYYYYY" >== "FAT32^@YYYYYYYYYYYYY"
It should be easy to copy/part find string "^@" or something like that, but, arent those additional parameters just pointers? Try change their typ, e.g. to [char*] and see what gets into buffers, maybe rebol will do it for you. I would also try to stop preallocating those buffers with content. What about make string! 100 or something like that? Dunno, let's hope some more experienced rebollers step-in here and give you the right answers ... cheers, -pekr-

 [4/8] from: rotenca:telvia:it at: 13-Dec-2004 15:04


Hi all, this stuff can be done, but in an insane mode. This is the hacked solution: kernel32.dll: load/library %/C/WINDOWS/system32/kernel32.dll GetVolumeInfo: make routine! [ disk [string!] lpVolumeNameBuffer [string!] size [integer!] lpVolumeSerialNumber [integer!] lpMaximumComponentLength [integer!] lpFileSystemFlags [integer!] lpFileSystemNameBuffer [string!] size2 [integer!] return: [integer!] ] kernel32.dll "GetVolumeInformationA" st: make struct! [ VolumeNameBuffer [string!] FileSystemNameBuffer [string!] ] reduce [VNB: make string! 100 FSNB: make string! 100] GetVolumeInfo "C:\" VNB 20 0 0 0 FSNB 20 probe st/FileSystemNameBuffer ;"NTFS" There are many points about my example code which should need a wish/issue/bug item in RAMBO.

 [5/8] from: petr:krenzelok:trz:cz at: 13-Dec-2004 15:20


Romano Paolo Tenca wrote:
>Hi all, >this stuff can be done, but in an insane mode.
<<quoted lines omitted: 20>>
>There are many points about my example code which should need a >wish/issue/bug item in RAMBO.
If there is any inconvenience or the way to help to improve library interface creation, do so, there is imo no need to let things work "old way".... -pekr-

 [6/8] from: patrick:philipot:laposte at: 13-Dec-2004 16:21


Hello Romano, RPT> st: make struct! [ RPT> VolumeNameBuffer [string!] RPT> FileSystemNameBuffer [string!] RPT> ] reduce [VNB: make string! 100 FSNB: make string! 100] RPT> GetVolumeInfo "C:\" VNB 20 0 0 0 FSNB 20 Thanks Romano Very strange indeed. And I don't get why it's working. It seems that Rebol is doing a lot of things behind my back. --- Ciao Pat

 [7/8] from: rotenca::telvia::it at: 13-Dec-2004 20:12


Patrick Philipot wrote:
>RPT> st: make struct! [ >RPT> VolumeNameBuffer [string!]
<<quoted lines omitted: 4>>
>Very strange indeed. And I don't get why it's working. It seems that >Rebol is doing a lot of things behind my back.
The fact is that a string! in a struct! is used by rebol like a C string (0 terminated). So st/FileSystemNameBuffer return a rebol string which ends at the first 0. But the problem is that you cannot pass st/FileSystemNameBuffer to GetVolumeInfo because st/FileSystemNameBuffer is indeed a Rebol string! copy of the C string in the struct. So I use this workaround: reduce [VNB: make string! 100 FSNB: make string! 100] where I get in FNSB a pointer to the C string and then pass that pointer to GetVolumeInfo: GetVolumeInfo "C:\" VNB 20 0 0 0 FSNB 20 You must think that st/FileSystemNameBuffer is a pointer to the same memory area pointed by FNSB, the difference is that when Rebol uses the first, it makes a copy of that memory only until the first 0; when Rebol uses the second, it reads it until the string! length (which is 0 until you insert something in it, so it is always "" in our example). So: probe st/FileSystemNameBuffer ; "NTFS" probe FSNB ; "" also if they share the same memory storage area. -- Ciao Romano Paolo Tenca

 [8/8] from: patrick::philipot::laposte::net at: 15-Dec-2004 10:27


Hello Cyphre, C> One thing I'd suggest to Patrick is to not load the system library with C> absolute path to achieve compatibility between different Win versions. Thank you for this input. It works for me. Perhaps what is missing is some get-Cstring function or something like the decode-cgi function. The documentation is unfortunately miserable in that particular area. As often it looks like unfinished business. -- Regards Patrick

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted