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: Charlie Gibbs on 25 Mar 2010 13:19 In article <5cc14b57-0396-45ea-a7f0-09b57688e35a(a)c20g2000prb.googlegroups.com>, davids(a)webmaster.com (David Schwartz) writes: > 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. That's why I write everything out as ASCII text. My preferred format is CSV, with the first field being a record type. This makes it extensible - if you want to save more data, just add more types. Programs that read these files simply ignore any types they don't recognize. Best of all, if everything goes south, you can examine or repair your files with a text editor, so even if things are so wrong that your program refuses to run, you can still quickly fix things up and get going again. CSV is easy to parse, so you don't have to tie yourself to proprietary program libraries that limit portability. -- /~\ cgibbs(a)kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
From: ScottMcP [MVP] on 25 Mar 2010 12:31 On Mar 25, 10:40 am, Piranha <eu_pira...(a)gmx.net> wrote: > 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?- Hide quoted text - If you have a struct in app A you would put the address of the struct, and its size, into the COPYDATASTRUCT. No conversion is necessary: Any pointer can be passed when a void pointer (PVOID) is the required parameter type. When app B receives the WM_COPYDATA message it also receives a pointer and size. The contents of the received struct can be copied using CopyMemory or memcpy. You would allocate a struct and use the address of that struct as the 'destination' parameter to CopyMemory.
From: Piranha on 25 Mar 2010 12:36 On 25 Mrz., 17:31, "ScottMcP [MVP]" <scott...(a)mvps.org> wrote: > On Mar 25, 10:40 am, Piranha <eu_pira...(a)gmx.net> wrote: > > > 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?- Hide quoted text - > > If you have a struct in app A you would put the address of the struct, > and its size, into the COPYDATASTRUCT. No conversion is necessary: Any > pointer can be passed when a void pointer (PVOID) is the required > parameter type. > > When app B receives the WM_COPYDATA message it also receives a pointer > and size. The contents of the received struct can be copied using > CopyMemory or memcpy. You would allocate a struct and use the address > of that struct as the 'destination' parameter to CopyMemory. CopyMemory ..... thats what I needed, thanks.
From: Jonathan de Boyne Pollard on 25 Mar 2010 15:06 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <blockquote cite="mid:cxJqn.15005$pv.8244(a)news-server.bigpond.net.au" type="cite"> <p>You are overreacting. </p> </blockquote> <p>No, xe isn't. He's stressing a basic lesson in program design that people who want to be future-proof and portable have to learn. Moreover, it's better to learn this lesson <em>before</em> one finds onesself locked into the limitations of a file format that one designed ten years ago, which in M. Piranha's case is <em>right now</em>. Go and read <a href="http://www.lysator.liu.se./c/ten-commandments.html">Henry Spencer's Tenth Commandment</a>, <a href="http://stackoverflow.com/questions/2193472/are-files-dumped-with-fwrite-portable-across-different-systems">the writings of Martin York</a>, or <a href="http://fadden.com./techmisc/file-formats.htm">the writings of Andy McFadden</a>. <em>Learn</em> from other people's mistakes in this area. There are enough examples of them to learn from.</p> </body> </html>
From: David Schwartz on 25 Mar 2010 17:43
On Mar 25, 6:27 am, "Leslie Milburn" <CD...(a)NOSPAM.bigpond.com> wrote: > > That still doesn't solve the case where the memory representation > > changes. > You are overreacting. No, I'm not. > If the memory representation changes then the > structure can be updated at a later time to reflect that and the original > order reconstructed. Sure, it *can* be, but *will* it be? Or will it instead cause horrible pain or, worse, silent bugs? > Anyway, the chances of this occurring is minimal This is like the "nobody dies" fallacy -- after all, nobody who is alive has died. The truth is the reverse, obsolescence is the certainty. > unless > you completely change compiler Which we do all the time. 16-bit compilers were replaced by compilers that target 32-bit platforms. Borland's compilers were once all the rage and are now gone. Intel's compilers and Microsoft's both have market share now. And lots of code that was never meant to run on a 64- bit platform is being made to do that right now. > and lets face it you might then also run into > left to right versus right to left evaluation differences as well. If your code depends on evaluation behavior that is not guaranteed by the language, you had better fix it. The next version of the same compiler might break it. And if it is guaranteed by the language, then you can rely on that guarantee. That's what such guarantees are for. > 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). Please let me know what software you have developed according to this philosophy so I can avoid it like the plague. I don't want to have to audit every line of code, and possibly rewrite huge chunks, just to upgrade my compiler. And god help me if I don't have the source code! This same philosophy leads to code that breaks on OS upgrades, CPU upgrades, library bugfix updates, and the like. If you're not around to (or willing to) rewrite all the code that broke, I won't even be able to do it myself. DS |