ReadFile() WriteFile()
in [Win32 API]
|
Prev: SymEnumSymbols is getting failed even GetLastError returns 0
Next: How to know function name by module version and logical address?
From: Friedel Jantzen on 25 Mar 2010 04:56 Am Wed, 24 Mar 2010 17:29:26 -0700 (PDT) schrieb David Schwartz: > On Mar 24, 10:00�am, "ScottMcP [MVP]" <scott...(a)mvps.org> wrote: > >> You can create a struct or class that contains all of the data members >> to be saved. �Something like >> >> struct config >> { >> int structlength; >> int x,y,dx,dy; >> char text[50]; >> ... >> >> } theconfig; > > No, you can't do that. Files are arrays of bytes and to have a file > format, it must have a defined structure for each byte. If the next > version of his compiler stores 'int's a different way, he won't be > able to read back the files he wrote out. > > DS You can set the alignment to byte to solve this problem: #pragma pack(push, 1) struct config { //... }; #pragma pack(pop) And use types of fixed size, e.g. unsigned __int32. IMO it is a good idea to set the first member to sizeof(config), as we can see it for many structs of the Win API. Friedel
From: David Schwartz on 25 Mar 2010 06:44 On Mar 25, 1:56 am, Friedel Jantzen <nospam_...(a)freenet.de> wrote: > You can set the alignment to byte to solve this problem: > #pragma pack(push, 1) > struct config > { > //...}; > > #pragma pack(pop) > > And use types of fixed size, e.g. unsigned __int32. That still doesn't solve the case where the memory representation changes. > IMO it is a good idea to set the first member to sizeof(config), as we can > see it for many structs of the Win API. Those structs typically use special types that have defined byte representations (DWORD, LARGE_INTEGER, and so on). And also that really should be classified as a design decision that has caused significant pain rather than as a model for future implementation. This is something that's so easy to do right I can't imagine why someone would want to do it such an ugly way. DS
From: Bob Masta on 25 Mar 2010 09:30 On Wed, 24 Mar 2010 17:32:47 -0700 (PDT), David Schwartz <davids(a)webmaster.com> wrote: >On Mar 24, 8:40=A0am, Piranha <eu_pira...(a)gmx.net> wrote: > >> I=B4m wondering, isn=B4t there an easier way, to read and write the data? >> I=B4ve considered making 2 files, a config.ini where I save strings in >> txt format and a config.dat where I save the rest binary, but I don=B4t >> like the idea of 2 separate files there. > >> Long speech short sense, how can I write a mixture of text and binary >> data into a file, and how can I read the the file again to split up >> the data and convert all pieces back to their types? > >You could reinvent the wheel if you want. But there are already lots >of solutions to exactly this problem. > >http://www.hyperrealm.com/libconfig/ >http://liblcfg.carnivore.it/ >http://linux.wareseeker.com/Programming/configuration-file-library-1.1.zip/= >326462 > >You could define a format that contains a name, a type, and a payload. >You could always include the length in each entry, or you could define >an 'end of entry' character. You can keep the data internally as a >linked list of parameters and also indexed as a hash table if desired. This is similar to RIFF, which would be a good model to use: 4 chars give the type of the field, then 4 bytes (DWORD) give the size, followed by the data itself in any format you like. No need to do any conversions. The next field type follows immediately. You can read the overall file sequentially, but you can also scan for a particular "chunk" (field) by walking the chain. The reading code can easily skip over any chunks it doesn't recognize, just by adding the size dword to the current pointer. That will point to the start of the next field name. This allows you to add new fields but still maintain backward compatibility since older versions of your app can just ignore them gracefully. Best regards, Bob Masta DAQARTA v5.10 Data AcQuisition And Real-Time Analysis www.daqarta.com Scope, Spectrum, Spectrogram, Sound Level Meter Frequency Counter, FREE Signal Generator Pitch Track, Pitch-to-MIDI DaqMusic - FREE MUSIC, Forever! (Some assembly required) Science (and fun!) with your sound card!
From: Leslie Milburn on 25 Mar 2010 09:27 "David Schwartz" <davids(a)webmaster.com> wrote in message news:5cc14b57-0396-45ea-a7f0-09b57688e35a(a)c20g2000prb.googlegroups.com... On Mar 25, 1:56 am, Friedel Jantzen <nospam_...(a)freenet.de> wrote: > You can set the alignment to byte to solve this problem: > #pragma pack(push, 1) > struct config > { > //...}; > > #pragma pack(pop) > > And use types of fixed size, e.g. unsigned __int32. > That still doesn't solve the case where the memory representation > changes. You are overreacting. If the memory representation changes then the structure can be updated at a later time to reflect that and the original order reconstructed. Anyway, the chances of this occurring is minimal unless you completely change compiler and lets face it you might then also run into left to right versus right to left evaluation differences as well. So, the solution is to code for today. Worst case, a conversion of the file can be done when the product is upgraded (which would coincide with a compiler change).
From: Piranha on 25 Mar 2010 10:40
On 25 Mrz., 14:30, N0S...(a)daqarta.com (Bob Masta) wrote: > This is similar to RIFF, which would be a good > model to use: 4 chars give the type of the field, > then 4 bytes (DWORD) give the size, followed by > the data itself in any format you like. No need > to do any conversions. The next field type > follows immediately. > > You can read the overall file sequentially, but > you can also scan for a particular "chunk" (field) > by walking the chain. > > The reading code can easily skip over any chunks > it doesn't recognize, just by adding the size > dword to the current pointer. That will point to > the start of the next field name. This allows you > to add new fields but still maintain backward > compatibility since older versions of your app can > just ignore them gracefully. That´s a great concept, in my case I think I can write the code for that myself, no need for a huge 3rd party library while I only need a small set of types. Just one follow up question, out of curiosity: Reading a file binary is nothing more than creating a variable of proper type or a struct, a pointer pointing at it, another pointer pointing at the right point in the file and do ReadFile(hFile,&variable,sizeof(variable),&dwRead,0); I don´t really have a practical example of what to use it for, but let ´s say I want to send the data to another window, or something like that, without a detour into/out of a file. Maybe I have 2 applications, where application1 allows the user to change some settings, like changing font and color in edit controls, where then application1 shall submit the changes to application2. Obviously application1 could write the data into a file and then send application2 a message to read the file, but it should also be possible to send the data directly, via WM_COPYDATA or so. What I don´t understand is the way how I could in this case convert the (binary) data to PVOID as required for the lpData member of COPYDATASTRUCT and then "read" the data, meaning binary read lpData as if it was reading a file content. I might be able to get the pointers right, but then I´m missing the corresponsing command to ReadFile(), my guess is I´d need strcpy() or something like that? |