Do the Intrinsic File Manipulation Commands of VB6 Utilize the API?

[SwampeastMike]

Am working on a program that for the first time involves tens of thousands of active files instead of tens of thousands of active members.

Also for the first time I'm making use of the API--and objects in general--due to the versatility they afford above the intrinsic file operations of BASIC.

But when I have altered code from BASIC commands to OOP during "development" it [seems] that speed decreases. The HDD activity led would [seem] to concur as the ordinarily buries it while the API results in flashing.

I've searched here and elsewhere to find no answer but I suspect that the intrinsic file commands operate at a lower level not involving the API.

If, instead VB does utilize the API for its file operations then it must be up to me to optimize the code and system utilization for speed.

[wqweto]

Which intrinsic file commands?

Btw, under Win32 API there is more API actually :-))

cheers,
</wqw>

[fafalone]

Put an API monitor on it and find out... but the question is whether it uses the regular Win32 API (CreateFile, ReadFile, WriteFile) or the Native API (NtCreateFile, etc). It's not a driver.

"The API results in flashing" -- with what flags. A lot of API-based file io codes I see use FILE_FLAG_WRITE_THROUGH which immediately puts it on disk when io is normally cached.

[SwampeastMike]

Which intrinsic file commands?

Btw, under Win32 API there is more API actually :-))

cheers,
</wqw>

Which intrinsic file commands?

Btw, under Win32 API there is more API actually :-))

cheers,
</wqw>

Would have sworn I posted this yesterday. Oh well.

The intrinsic commands I'm referring to are:

FILECOPY <filespec1>, <filespec2>

NAME <filespec1> AS <filespec2>

KILL <filespec>