Robert L Krawitz wrote: > > This sounds a lot like how shared libraries (and indeed, shared text > in general) work, but it's not enough to solve the problem. If you > run multiple copies of an application (on most UNIX-like operating > systems, and even Windows is probably smart enough these days), there > will be only one copy of read-only memory, and read-write data will be > copied on write. That's strictly an efficiency issue, though; it > doesn't change the programming model. > > Netscape actually runs only one instance, with multiple windows (and > multiple threads sharing one address space). You'll note that if you > try to start a second Netscape from the command line with one running > you'll get a warning that it won't be able to use your history, > certificates, or anything else. This is because Netscape isn't able > to arbitrate between multiple instances modifying the same file > concurrently (or even accessing it where one instance might change > something). Multi-threaded programming is considerably more difficult > than single threaded programming, and I guess Netscape decided to only > go so far (make the application MT, but not arbitrate between multiple > instances). The problem with MT programming, of course, is that if > you get the synchronization wrong things blow up in your face, usually > in very hard to debug ways. > Hello Robert, Thank you for the explanation. I can understand the problem of saving preferences if someone has several instances of an application open. Do you know what Gimp does? My preference would be to keep the preferences from the last instance closed and just throw away anything from another instance unless the user specifically applies the change to their profile. If someone had open instance3 A and B, and manually saved a setting in A, I would have an option to "save as default for future sessions. Instance B would detect that there was a default set and not save over the top. If the value is not flagged as a default, then B would write over it when B closed. The only instance I can think of where I would want multiple instances updating each other, is when I create a new brush definition in once instance, and want it immediately available in all others. I certainly do not want to change the current selection in the others, which is one problem with PSP. In the Windows world, and a few others, people have a hard time because they use objects and other techniques to make their code fuzzy. Like all fuzzy logic systems, it is hard to see what is happening so is hard to test. When they move an application from Windows to NT, the application users start finding millions of errors caused by data mixed in with code, data not defined as read data versus update, system data avaulable for update by users and an endless list of similar style design and coding faults. I worked on a number of projects to fix n-tier applications by reducing them to 2-tier or 1-tier. If some of those n-tier systems were buildings, they would have been building from the roof down. Do you know of a good, simple explanation of GTK? One that has diagrams and stuff that can be read and understood without knowing C? If I had to build a house using plans written in C, the electricity outlets would produce water and touching a kitchen cupboard knob would turn all the windows blue :-) Peter
