Forum > Windows
What WinAPI functions can be used to save a file to a folder at a network drive?
Tikani93:
I have a Lazarus Win32 project, where some PDF files are downoaded with HTTP client into RAM-allocated buffer as a sequence of bytes. After downloading, it should be saved to a folder at a network drive, addressed by UNC. What a function should I use?
As far as I known, only a small subset of Win32 API functions make no difference between local/remote (UNC) paths and simply works.
Fibonacci:
Take your pick
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---uses Windows; var h: hwnd; s: string; byteswritten: dword; begin h := CreateFile('\\nas\pub\test.txt', GENERIC_WRITE, FILE_SHARE_READ, nil, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0); s := 'hello'; WriteFile(h, s[1], length(s), byteswritten, nil); CloseHandle(h);end.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---uses Classes; var s: string; begin s := 'hello'; with TMemoryStream.Create do begin Write(s[1], length(s)); SaveToFile('\\nas\pub\test.txt'); Free; end;end.
Gustavo 'Gus' Carreno:
Hey Y'All,
Please excuse my lill rant. And this being a rant, it's not directed at anyone in particular, so please chill.
I'm fully aware that not everyone is as gung-ho on multiplatform compatibility as I am. And, yes, sometimes you're absolutely sure your app will only be run in a single platform, so why even bother.
But I also have another principle: Please make good use of the batteries that are included in your language. Heck, this is what makes Python so enchanting. You're spoilt rotten from the massive modules/libs/frameworks that it has.
So, my main point is: Why not just use FPHHTPClient and a File Stream?
First of all it forgoes the old file management system with something a bit more modern.
Ok, sure, if you wanna do HTTPS, especially under Windows, the OpenSSL .dlls are a pain to provide. And yes, I'm aware that under Linux we are spoilt rotten because OpenSSL usually comes installed by default in all major distributions.
End of rant!
Now, for Tikani93 in particular:
Were you aware of FPHHTPClient?
Were you aware of File Streams?
One of the awesome things about the above combo is that you pass a File Stream to FPHHTPClient and BOOM, done!!
The download is saved into the file with a single line of code ( Yes, I'm not counting the instantiation and setup of both objects ).
It's easy: You pass the file stream object to the HTTP client and press a button. No need to do in memory shenanigans by hand, because it's all managed by the File Stream.
Let me know what you have to say to this, please.
Cheers,
Gus
440bx:
--- Quote from: Gustavo 'Gus' Carreno on June 22, 2025, 05:33:33 pm ---So, my main point is: Why not just use FPHHTPClient and a File Stream?
--- End quote ---
One reason could be that the same program written using FPHHTPClient will be about 8 times larger than the same program written using WinHTTP. I personally have tested that, a simple program that takes 50k using WinHTTP takes about 400k using FPHHTPClient and, as you mentioned, the additional libraries that are not required using WinHTTP.
In addition to that, when using FPHHTPClient there is a lot more code that can wrong, potentially making debugging more laborious. FPHHTPClient is great when everything works fine but, the additional code means additional work when something, for whatever reason, does not work.
Libraries are double edged swords. When they work, it's great, when they don't they are usually a black hole of code that is not easy to debug for someone who isn't intimately familiar with them.
All that said, in fairness, WinHTTP has security handshaking problems that can be next to impossible to solve (in Win 7, none in Win 10). For instance, accessing MS' website using WinHTTP is no problem at all (in Win 7 and Win 10). Accessing this forum, i.e, the Lazarus forum, with WinHTTP is in some cases next to impossible because of mismanagement of security protocols on the Windows side (not the Lazarus server.) In Win 7 it doesn't work while the same executable works like a charm in Win 10. That is one reason to use FPHHTPClient and, basically, the only reason I've used it.
Like everything, there are pros and cons to it.
Gustavo 'Gus' Carreno:
Hey 440bx,
--- Quote from: 440bx on June 22, 2025, 07:11:29 pm ---One reason could be that the same program written using FPHHTPClient will be about 8 times larger than the same program written using WinHTTP. I personally have tested that, a simple program that takes 50k using WinHTTP takes about 400k using FPHHTPClient and, as you mentioned, the additional libraries that are not required using WinHTTP.
In addition to that, when using FPHHTPClient there is a lot more code that can wrong, potentially making debugging more laborious. FPHHTPClient is great when everything works fine but, the additional code means additional work when something, for whatever reason, does not work.
Libraries are double edged swords. When they work, it's great, when they don't they are usually a black hole of code that is not easy to debug for someone who isn't intimately familiar with them.
All that said, in fairness, WinHTTP has security handshaking problems that can be next to impossible to solve (in Win 7, none in Win 10). For instance, accessing MS' website using WinHTTP is no problem at all (in Win 7 and Win 10). Accessing this forum, i.e, the Lazarus forum, with WinHTTP is in some cases next to impossible because of mismanagement of security protocols on the Windows side (not the Lazarus server.) In Win 7 it doesn't work while the same executable works like a charm in Win 10. That is one reason to use FPHHTPClient and, basically, the only reason I've used it.
Like everything, there are pros and cons to it.
--- End quote ---
First and foremost, I must thank you, very much, for taking my rant and giving a, rather, thoughtful consideration and rebuke.
Secondly, I need to thank you for your experimentation in this aspect, especially with the MS/Forum shenanigans under Windows versions. This gives the community at large some answers that may have confounded them.
Thirdly, more thanks due to the fact that some of the stuff you mention about program size, I wasn't really aware of and it's a welcome piece of knowledge to know !!
Finally, I do have to agree the "Your mileage may vary" is quite pertinent in this case!!
This has also brought back the memory of a problem that I've got when using the internet via mobile tethering when using FPHTTPClient, where the download is just dropped at about 70% of completion.
I need to understand if this is a specific issue with FPHTTPClient, or if it's a problem specific to my own phone's tethering. I'll need to conduct some experiments with either Indy or Synapse.
Cheers,
Gus
Navigation
[0] Message Index
[#] Next page