"Gregory M. Turner" gmturner007@ameritech.net writes:
Would love to hear if I have not done things in a properly "SETUPAPI" way, i.e., am I supposed to be performing certain logging or memory allocation rituals, anything like that?
One ritual is that you should not use msvcrt from other dlls, this will cause trouble with apps that use the Unix libc.
On Tuesday 12 August 2003 03:57 pm, Alexandre Julliard wrote:
"Gregory M. Turner" gmturner007@ameritech.net writes:
Would love to hear if I have not done things in a properly "SETUPAPI" way, i.e., am I supposed to be performing certain logging or memory allocation rituals, anything like that?
One ritual is that you should not use msvcrt from other dlls, this will cause trouble with apps that use the Unix libc.
That was a bit of laziness and is definitely fixable. Worst case, it will require that I "re-implement" _open() & family within setupapi, in terms of CreateFile & family. Presumably, just such code can be found in the msvcrt sources -- unless somebody knows some kernel32 place, or some more obscure place, where I could find similar functions (to _open, _close, _read, _write, & _lseek) already linked to setupapi?
On Tuesday 12 August 2003 03:57 pm, Alexandre Julliard wrote:
"Gregory M. Turner" gmturner007@ameritech.net writes:
Would love to hear if I have not done things in a properly "SETUPAPI" way, i.e., am I supposed to be performing certain logging or memory allocation rituals, anything like that?
One ritual is that you should not use msvcrt from other dlls, this will cause trouble with apps that use the Unix libc.
Is it OK to do LoadLibrary/GetProcAddress, or is that equally problematic?
"Gregory M. Turner" gmturner007@ameritech.net wrote:
One ritual is that you should not use msvcrt from other dlls, this will cause trouble with apps that use the Unix libc.
Is it OK to do LoadLibrary/GetProcAddress, or is that equally problematic?
Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite exported from kernel32?
Dmitry Timoshkov wrote:
"Gregory M. Turner" gmturner007@ameritech.net wrote:
One ritual is that you should not use msvcrt from other dlls, this will cause trouble with apps that use the Unix libc.
Is it OK to do LoadLibrary/GetProcAddress, or is that equally problematic?
Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite exported from kernel32?
except for _lopen which differs a bit from CreateFile, but why not using ReadFile, WriteFile, CloseHandle... A+
"Eric Pouech" pouech-eric@wanadoo.fr wrote:
Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite exported from kernel32?
except for _lopen which differs a bit from CreateFile, but why not using ReadFile, WriteFile, CloseHandle...
Because they look too hard for Gregory... Did you read the whole thread?
Dmitry Timoshkov wrote:
"Eric Pouech" pouech-eric@wanadoo.fr wrote:
Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite exported from kernel32?
except for _lopen which differs a bit from CreateFile, but why not using ReadFile, WriteFile, CloseHandle...
Because they look too hard for Gregory... Did you read the whole thread?
yes I did... but I don't so many differences between read and ReadFile... which is not as easy for open vs. CreateFile as I wrote
A+
On Saturday 16 August 2003 03:14 am, Eric Pouech wrote:
Dmitry Timoshkov wrote:
"Eric Pouech" pouech-eric@wanadoo.fr wrote:
Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite exported from kernel32?
except for _lopen which differs a bit from CreateFile, but why not using ReadFile, WriteFile, CloseHandle...
Because they look too hard for Gregory... Did you read the whole thread?
yes I did... but I don't so many differences between read and ReadFile... which is not as easy for open vs. CreateFile as I wrote
Looking at msvcrt's code, it starts to look like a bit much. Take a peek at dlls/msvcrt/file.c, "_open" and "MSVCRT__sopen" functions to get an idea of what I was hoping to avoid. Looking at dlls/kernel/file.c, somehow things are much simpler (!?). I will do some experimentation with "_lopen" and co. (and read the api doc on MSDN) but presumably -- hopefully, judging by the names -- the "_l" API's will be close enough to "_open" & co. to avoid some cut-and-paste development. If not... there's more than one way to skin a cat.
Looking at msvcrt's code, it starts to look like a bit much. Take a peek at dlls/msvcrt/file.c, "_open" and "MSVCRT__sopen" functions to get an idea of what I was hoping to avoid.
msvcrt does a lot more than you need (and also a bit more than the standard C library).
Looking at dlls/kernel/file.c, somehow things are much simpler (!?). I will do some experimentation with "_lopen" and co. (and read the api doc on MSDN) but presumably -- hopefully, judging by the names -- the "_l" API's will be close enough to "_open" & co. to avoid some cut-and-paste development.
Normally, the _l* API is very close to the C standard library, but moving to the win32 API is not too hard.
If not... there's more than one way to skin a cat.
Windows surely does provide lots of tools for this to happen A+
On Saturday 16 August 2003 02:25 am, Eric Pouech wrote:
except for _lopen which differs a bit from CreateFile, but why not using ReadFile, WriteFile, CloseHandle... A+
After consulting some doc, it seems CreateFile is actually easier to use than _lopen, if only trivially so, due to the layout of the flags. Also, _lopen is officially depreciated.
So, I am mostly stealing from msvcrt, and omitting several features SetupIterateCabinet probably won't need. So far, it has proven most painless, consuming approximately 100 lines of code (although it is untested so far). Thanks for your advice.
-
Alexandre Julliard -
Dmitry Timoshkov -
Eric Pouech -
Gregory M. Turner