|
I think this will work:
void Yield()
{
MSG msg;
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
for ...
{
Yield();
}
Jason Henderson
quasi-homepage
articles
"Like it or not, I'm right!"
|
|
|
|
|
Thankyou, works perfectly.
|
|
|
|
|
Hi all,
I want to make a file system driver to access BeOS partitions from windows 2000. I am having a hard time learning how to get access to the partition info and how to mount a drive so that I can then access the foreign file system.
I guess after I am successfull in mounting a drive (including all the code to read and write) I will need to make it a shell extension so that it shows up transparently in Explorer? Is that right?
Any pointers to tutorials, source code, etc. would be greatly appreciated.
Cheers,
Clint
|
|
|
|
|
I think you will find open source filesystem drivers for NTFS,ext2(Linux) at sourceforge.net very illuminating.There are a couple of Beos ports to NTFS drivers too(I think).
sonork: 100:18407
You yard yellow years yieldingly; you yanked your yearning yoke.
-Jeremy Falcon
|
|
|
|
|
Then you're in for a treat. Not!
MS has the FSD SDK for $5k (or is it perhaps $10k+ nowadays?) with no support, sparse documentation and no promises they won't change everything behind your back even from service-pack to service-pack, making this one of the "great developer experiences" that MS loves to force down our throats with a rough 2-by-4 without any K-Y.
Good luck, I really think you need it.
I guess after I am successfull in mounting a drive (including all the code to read and write) I will need to make it a shell extension so that it shows up transparently in Explorer? Is that right?
No. Once you have the filesystem mounted it's just like any other filesystem (except that you can't use half of the features in BFS on this DOS-emulation platform). You perhaps could get access to the attributes using the NT-only syntax for alternate file streams "filename:stream_name", but since you'd be the only one using it (since it's incompatible with everything except NTFS almost no-one ever uses it) you'd (obviously) have to write your own programs to access that too.
The only place I can point you to is http://ntfsd.org
++luck;
|
|
|
|
|
Thanks for you information. I am too poor to afford anything so I guess the FSD SDK is out of the question.
One thing I would like clarification on is about the dos-emulation layer you mentioned. I am aware that there is an emulation layer but are you saying I could write a driver for dos and use it to access another filesystem from within win2k?
Thanks again,
Clint
|
|
|
|
|
One thing I would like clarification on is about the dos-emulation layer you mentioned.
I forgot to add the <sarcasm> tag. I was referring to the fact that Win32 is little more than MS-DOS with longer filenames when it comes to filesystem and filename handling.
I'm sorry if it got your hopes up.
|
|
|
|
|
Doh... I should have known better. I didn't dismiss the idea because I did read bout something like that years ago where int 0x21 was extended for Win95 to support the long file names and such. I guess I just thought there might be something for mounting partitions.
If you have done anything like this could you please check out my last post. I have source code to read from the disk sectors but it fails on ReadFile.
Thanks again,
Clint
|
|
|
|
|
I'm having the most difficult time determining the cause of a bug somewhere
in the heap manager (I'm guessing?).
I'm using Windows 2000 SP2, with MSVC 6.0 SP5, and ATL 3.0.
In my application, *sometimes*, when adding a treeview item, the memory
allocated internally by comctl32.dll for the item is later overwritten by a
call to RegQueryKeyValueEx(). As a result the treeview is corrupted, and
the application becomes unstable. The default process heap is being used in
both allocations, and both allocations are happening on the same thread.
Here is an assembly listing of the code before and after the call to
HeapAlloc() in comctl32:
_text:7179A8ED push 24h ; dwBytes
_text:7179A8EF push 8 ; dwFlags
_text:7179A8F1 push dword ptr [edi+94h] ; hHeap
Values at ESP before the call ... 130000 seems to be the default heap
00130000 00000008 00000024
_text:7179A8F7 call ds:HeapAlloc
eax after the call to HeapAlloc() is 172de0
Now, after the treeview item is added, the _ATL_DEBUG_INTERFACES macro
queries the registry for the value of an interface name ... and this code is
in advapi32.dll!RegQueryKeyValueEx:
_text:77DB2B3E push ecx
_text:77DB2B3F push edx
_text:77DB2B40 push dword ptr [eax+18h]
ESP before the call:
00130000 00000000 00000024
_text:77DB2B43 call ds:__imp__RtlAllocateHeap@12
eax after the call to __imp__RtlAllocateHeap@12() is 172de0!
How on earth can HeapAlloc() be returning the same value twice?
Now the interesting part is that if I define the DisableHeapLookAside value
in the Image File Execution Options, everything works fine, and HeapAlloc()
never returns duplicate values. If I do a HeapValidate() on the treeview
hItem value, sometimes it fixes it. I've also instrumented all my code with
Boundschecker, and it reported no memory corruption issues.
After checking the KB, I found article Q195009, which describes the Heap
Manager change in NT4 SP4 ... and goes on to say that sometimes the cause of
this bug is when an application uses memory previously freed. So I set some
breakpoints on HeapFree() calls, but never saw the pointer being freed
between the two calls to HeapAlloc().
My real question is why is this happening to begin with, and what does
DisableHeapLookAside do to cause the problem to go away?
Thanks in advance,
Scott.
|
|
|
|
|
You also have to monitor HeapReAlloc in addition to HeapFree.
Before jumping to conclusions, have you tried this with a "checked build" and/or using e.g Purify or something similar to really rule out the possibility that your application is overwriting some heap memory it doesn't own? If you're longing for an adventure you might even replace the malloc/free implementation functions from the CRT with your own functions that use a private heap.
If it is beyond all dubt ruled out that the a memory overflow bug is introduced by your app, one can only conclude that it has to be a bug in the NT heap manager and you should notify MS of this ASAP.
If this is an MS bug I could guess that they don't have a (nasty enough) regression test for HeapReAlloc and the heap lookaside combination (which I personaly think is a fairly reasonable guess).
The following assumes the bug is not in your code:
My real question is why is this happening to begin with
Bugs in the heap manager implementation.
what does
DisableHeapLookAside do to cause the problem to go away?
Answering that question would probably involve explaining how their NT4sp4+ and NT5+ heap manager works in such a detailed way that one could write it oneself. That would probably violate some kind of "trade secrets". 
Please check HeapReAlloc also and report back. This can become interesting (unless it's a bug in your code)!
|
|
|
|
|
Hi,
Thanks for the reply ... I was wondering if my question was even going to get one
I've done a full instrumentation of all the entire using Boundschecker, and no memory overwrites turned up. Maybe I should have mentioned in my original post that not a lot of code is being executed in the time it takes HeapAlloc() to spit out the duplicate pointer.
Basically, the structure of code is like:
Call one event sink
Insert the treeview item (first pointer)
Enumerate the treeview using TVM_GETNEXTITEM to ensure the item was added
Call next event sink
ATL event tracing (duplicate pointer)
I'd estimate that there were about ~30 calls to HeapAlloc in the time between the duplicate pointer returns.
I didn't check calls to HeapReAlloc, but I'll do that and post my results.
Fortunately, at work we have an MSDN subscription which includes 2 developer support calls, and I've been authorized to use one of them for this particular instance ... so hopefully I'll get an answer sometime soon.
Thanks for the help,
Scott
|
|
|
|
|
Just a though that struck me. If you can write some code before that "ATL event tracing (duplicate pointer)", and you can duplicate the bug even if you break into a debugger (which it seems you can), what about using a local variable and set it (using the debugger) to point to the memory you think is already allocated (but the "second" allocation returns) and just call IsBadReadPtr/IsBadWritePtr on it?
OK, checking HeapReAlloc isn't gonna hurt, but it never hurts to exhaust all options before that "support" call either.
|
|
|
|
|
Well,
I after adding the treeview item, I set a breakpoint on all HeapReAlloc() calls, and it was hit one time, on a call to realloc(), which is using the CRT heap ... aside from that, the GetProcessHeap() heap wasn't touched by any HeapReAlloc calls.
I tried your last suggestion ... I took the HTREEITEM returned by the TVM_INSERTITEM (which actually points to a 0x24 byte internal structure ... gotta love reverse engineering MS dll's) and called IsBadReadPtr(hItem, 0x24), and it returned 0 so ... hmmm ...
If you can think of anything else, let me know ... I feel as though I've tried every thing conceivable 
Thanks,
Scott.
|
|
|
|
|
If i do this:
char s[] = "hello\nhow\nare\nyou\doing"
SetDlgItemText(ghWnd, IDC_EDIT, s);
then a newline doesen't appear, only a "|". what am i doing wrong? and it doesen't work if i use \r instead of \n either.
|
|
|
|
|
|
use "\r\n"
like this char s[] = "hello\r\nhow\r\nare\r\nyou\r\doing"
Casa.Sapo.pt
|
|
|
|
|
Hi,
I know it is a VC++ forum, but i really need help!!! Let's see my code first:
********************************************************************************
void operation(int[], char[]);
void waitprocess(int);
void main(void)
{
int i, j;
static char buffer[BUFSIZE+10], X_value[5], message[BUFSIZE];
int f_des[2];
if (pipe(f_des) == -1) //create the pipe
{
perror("Pipe");
exit(2);
}
if (fork()==0) //In the CHILD
{
// do nothing here because we will
// create 5 CHILDs by PARENT again later.
}
else //PARENT
{
for (j=1; j<=5; j++) //create 5 CHILD process
{
if (fork()==0)
{
static char temp[BUFSIZE];
sprintf(temp, "Thread %d", getpid()); //Get the thread ID
operation(f_des, temp); //Send the request
}
}
while (X>0) // keep doing (read from pipe) until X=0
{
close(f_des[1]);
if (read(f_des[0], message, BUFSIZE) != -1) //Read from pipe
{
sprintf(buffer, " - X = %d \n", X);
strcat(message, buffer);
write(1, message, sizeof(message)); //display output
waitprocess(getpid()); //force sleep awhile
X--;
}
else
{
printf("error");
}
}
}
}
********************************************************************************
I have to create 5 "threads" but using fork() because i have to use pipe() to communicate with "server". This program is doing that 5 "threads" are trying to decrement the global X until X=0. I use pipe as a mechanisam to protect this "critical section". I don't know whether i did it right or wrong. Please help me to check!!!
Also, I found that the output looks strange. The output is always in a pattern. For example, the output looks liked:
Thread 1001 - X = 20
Thread 1003 - X = 19
Thread 1002 - X = 18
Thread 1005 - X = 17
Thread 1004 - X = 16
Thread 1001 - X = 15
Thread 1003 - X = 14
Thread 1002 - X = 13
Thread 1005 - X = 12
Thread 1004 - X = 11
*
*
*
You can see the sequence is 1,3,2,5,4,1,3,2,5,4...etc. I think the output should be in random sequence. Why it's happened???
Thanks!!!!! 
|
|
|
|
|
Hi,
how can I change my window dimension at runtime?
Is there something better as SetWindowPos() or how do I use it to change only the window size (position stays untouched)?
Thanks
|
|
|
|
|
Try MoveWindow which is an easyer way of calling SetWindowPos.
rechi
|
|
|
|
|
Use SWP_NOMOVE | SWP_NOZORDER in the "nFlags" argument of CWnd::SetWindowPos(). This will cause only the window's size to be changed.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Okay, I use this code now:
RECT winRect = {0, 0, nWidth, nHeight};
AdjustWindowRectEx(&winRect, WS_OVERLAPPEDWINDOW, FALSE, WS_EX_APPWINDOW | WS_EX_WINDOWEDGE);
SetWindowPos(m_data.hWnd, HWND_TOP, 0, 0,
winRect.right-winRect.left,
winRect.bottom-winRect.top,
SWP_NOMOVE|SWP_NOZORDER|SWP_NOCOPYBITS);
I still have a problem: When the window is maximized and I change the dimensions with my code, the maximize button is not changed. Instead Windows thinks my window is still maximized.
Any ideas? Thanks for help again!
|
|
|
|
|
Performing a ShowWindow(m_data.hWnd, SW_RESTORE) before resizing did solve the problem.
|
|
|
|
|
PS: This should be the subject for last post
|
|
|
|
|
Does SetSize method of IStream preserve the information existing in the stream object if the new size is smaller then the previous one?
rechi
|
|
|
|
|
It should truncate it I think. It might depend on the IStream implementation though. Best is to make a test program. Create an IStream working on global memory (use StreamFromHGlobal() or something like that) and write to it, then setsize then read it back.
James
Drinking In The Sun
Forgot Password?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
