|
Cris wrote: But, why the UAC configuration cause this problem?
Because you were trying to access an object in the c:\windows folder. Most everything in Vista has been locked down.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: Because you were trying to access an object in the c:\windows folder.
bingo... you beat me to it.
I am trying to be good an hang out here more often. 
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Why would UAC interfere with a call to read an INI file?
|
|
|
|
|
Michael Dunn wrote: with a call to read an INI file?
you are outside of your "accessable" directories. Even in XP you can restrict access to windows, or program files. theoretically you should only have read or write access to your program's director and sub-directories. even if you were to try ../common/config.ini if you have security set to full it will refuse you read access. We had to get an exception for our software for a few years until I got everything moved to the install folder... bad habits die hard...
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
That still doesn't explain why would UAC interfere with a call to read an INI file. Restricting access to \windows makes no sense - how would you use the computer if you couldn't access \windows?
|
|
|
|
|
Michael Dunn wrote: That still doesn't explain why would UAC interfere with a call to read an INI file. Restricting access to \windows makes no sense - how would you use the computer if you couldn't access \windows?
No one is supposed to have direct access to windows, windows does, but not the programs. We've just been too accustomed to lower security.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Hello,
I have a application that use the OnPrint() MFC class. This application work allready 2 years without problem.
Now I see the preview and it's look good , but when printing I geet a blank page. The printer is the same and also the driver.
Do have any one a idee? What cann I check to fix my problem.
Thank you to help me.
AutreChien
|
|
|
|
|
NorGUI wrote: What cann I check to fix my problem.
The printers toner cartridge.
|
|
|
|
|
We used to have a problem like that when users would have the option to change background and foreground colors in the app. They would make the background black and the foreground white, but the app would force a white background during printing but leave the foreground white.
They didn't have print preview however, so I'm not sure if this could be related but I thought I'd post it as an idea.
|
|
|
|
|
I am currently involved a project that requires that I have random access to multiple files on disk. I have a single 'file writer' object that handles writes, but I am unsure about how to proceed with reads.
The question is: If I want to be able to service multiple 'reads' at the same time to a single file should I have a single object (an fstream) that is synchronized (using a lock) or multiple fstream objects that are independent. I want to take advantage of my raid hardware as well as multiple processors throughout the application. My initial thought is that having multiple 'reader' objects leaves synchronization up to the OS, and that using some type of locking mechanism (such as a criticalsection/mutex) could slow performance.
Any help here is much appreciated.
On a side note: If I'm just writing buffers of data (or 1 byte aligned structures) does it make more sense to just use stdio functions?
|
|
|
|
|
KenThompson wrote: My initial thought is that having multiple 'reader' objects leaves synchronization up to the OS
What OS and where is it documented that it performs such synchronization. And by this I assume you mean synchronization to the "write operations".
KenThompson wrote: and that using some type of locking mechanism (such as a criticalsection/mutex) could slow performance.
"would" slow performance, it's not in question. However without the OS performing synchronization, of which I am unaware, you would have to do it to avoid reading corrupted data. You could optimize by creating a far more complex mechanism like Databases do of managing what "parts" of the file are locked for writing. Which of course raises the question of why you wouldn't just just use a database because they already implement everything you require.
Also you are not clear if this is across threads or across processes. The later synchronization is far more expensive.
|
|
|
|
|
I'm already synchronizing write and read operations. By this I mean that I keep track of what is currently being done to the file. Basically, the writer never goes backwards, so whatever has been written is fair game in regards to reading. The only random access is reading. A database for this application isn't acceptable.
The question remains though. What approach is the best? Have a single reader per file handling many requests. (ie. setg to the offset) or having several fstream objects created that read independently, in a shared mode.
I didn't mean that the OS, in this case Windows, prevents corruption when modifying files. I should of been more clear in my statement. I meant to say: My initial thought is that having multiple 'reader' objects is perfectly acceptable and not a performance hit. In addition, in a raid situation would it not make more sense to create multiple file streams to the same file due to the very nature of multiple disk heads? I'm not all that aware of where there is any performance to gain based on implementation. I can only assume that if I issue two reads to the same file, via two streams, that the raid controller (in my case raid 5) would out perform a setg operation. Maybe not with 2 reads, but maybe 100s of reads per second. Does this make sense?
|
|
|
|
|
KenThompson wrote: Does this make sense?
Absolutely. It would seem, on the surface (not a valid assessment), that multiple readers would be much more efficient. You might consider just implementing that and then run a profiler and see if that area even stands out at all. Sometimes (usually) profiler results will surprise you. 
|
|
|
|
|
Thanks, I needed some sanity here. What type of profiler do you use? I've been playing with a few intel products, but the cost sours me to them.
|
|
|
|
|
QC mostly runs them (several). I think the last time I used one myself it was an Intel product. The company has lots of money so cost is not an issue.
|
|
|
|
|
KenThompson wrote: A database for this application isn't acceptable.
So its better to write half of a database on your own instead of using e.g. SQLlite[^]?
KenThompson wrote: Does this make sense?
I think no. You would only ever work on buffers managed by the OS. The Harddisk-Heads would ascend and decend its cylinders all the time, doing the read/write out of order.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
SQLite is designed for use with databases sized in kilobytes or megabytes not gigabytes. Therefore, it is unacceptable.
|
|
|
|
|
IOCP - not just for sockets, they can be used with any IFS based HANDLE e.g. sockets, files, pipes, ...
Scatter/Gather I/O functions:
http://msdn2.microsoft.com/en-us/library/aa365472.aspx[^]
http://en.wikipedia.org/wiki/Vectored_I/O[^]
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thank you, this suggestion has proved quite fruitful!
Ken
|
|
|
|
|
Can someone please post the code (or an outline) for creating a UDP Server, just want the data to be transmitted even when the client is down - is that possible.
I get a bit confused with the calls.
Andy.
|
|
|
|
|
Andy202 wrote: Can someone please post the code (or an outline) for creating a UDP Server
You mean like the MFC/C++ article here on CodeProject titled "A simple UDP time server and client for beginners"?
No, no one can do that.
|
|
|
|
|
Hello comunity,
is it posible to protect environment variable in multithreaded application,
to ensure that only one thread can use this variable, for manipulations!
I want to protect one vector to be sure that only one thread can remove item from this vector?
I think on something like this:
//
LockVector;
DeleteItemFromVector;
UnlocVector;
From here allow all access to my vector! :->
thanks in advance
termal
|
|
|
|
|
EnterCriticalSection();<br />
LeaveCriticalSection();
|
|
|
|
|
termal wrote: ...to ensure that only one thread can use this variable, for manipulations!
Have you considered a synchronization object such as a critical section or a mutex?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hello,
thanks for reply,yes i use critical section, but only in one function,
is it posible to protect one variable programwide,
so wenn one function use vector other functions have to wait until this vector is free?
Example:
FunktionOne() // use vector
FunktionTwo() // must wait because vector is in use by FunktionOne()
Is that posible or i want to much?
with best regards
termal
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
