|
Command.com is a part of good old DOS. Windows 95/98/ME also have it for the command prompt. Its something like cmd.exe(Command Prompt) in Windows 2000/XP.
Since .com files are deprecated in Win2K/XP, Windows has to emulate a Virtual DOS Machine(VDM) in order to be able to run command.com. As a matter of fact, you are running a VDM instead of command.com when you are executing command.com, and Redir32.exe and WinOldAp.exe are parts of VDM and that's what Windows "Process view" sees instead of command.com.
Hope it helped.
|
|
|
|
|
|
Geek humor. 
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
The dll I wrote which has some shared data segment that being used by mutiple exes compiled on 32bit compiler and it worked. However, as I compiled the same project using the amd64 compiler by microsoft SDK 1415 and tested on x64 system, the shared data doesn't seems to be working anymore(each exe seems creates its own copy of those variables). I am wondering is there something changed on amd64 compiler that I did not notice. Anyadvice will be appreciated. t
This is how I did to create the shared variables
#pragma data_seg(".timerTOD") // shared with all procs
struct something
{
double a
int b
} variable_name = {0};
#pragma data_seg() // back to normal data
#pragma comment(linker, "/SECTION:.timerTOD,RWS")
|
|
|
|
|
Don't know if it will help, but we use the
#pragma data_seg( ".MyName" )
in the source file and
SECTIONS<br />
.data READ WRITE<br />
.MyName READ WRITE SHARED
in the module's definition file.
Maybe the AMD compiler/linker does not know the pragma
#pragma comment(linker, "/SECTION:.timerTOD,RWS")
|
|
|
|
|
Are the exes and the dll all compiled with the 64-bit compiler?
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi!
My application is automatically started when Windows is lauching. Sometimes Shell_NotifyIcon will fail. I do not have an error code since I haven't been to reproduce that bug very often.
My guess is that the desktop is not ready or something. Do you think that it would be safe to do something like:
BOOL bRes;
do
{
bRes = Shell_NotifyIcon(...);
}while(bRes = FALSE);
Thanks!
|
|
|
|
|
I can't remember it exactly (it's in my BugReporter article here on CP), but there's a way you can register a message to notify you when the taskbar gets repainted so that you can put the icon back in the system tray. Otherwise, when explorer.exe crashed and restarted, my icon would be gone from the system tray.
I don't know if that helps any, but I tried. 
My articles
www.stillwaterexpress.com
BlackDice
|
|
|
|
|
LukeV wrote:
Do you think that it would be safe to do something like:
No. If there's an error with your input you'll have yourself a nice little infinite loop.
I had this happen to me last night, although it happened for all programs. It turned out I had a virus, so I did a system restore and it's all good now . I doubt that's your problem though.
I've never had any problems with applications I've written doing this. I've heard of a few programs that add a few seconds delay during their startup to give Windows time to initialise properly. That might cure the problem. Other than that, there's not much you can do other than verifying that your input is correct.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi,
I utilize Visual C++ .NET 2003 with MFC.
When I open a file, MFC works with Serialize(CArchive& ar) method.
ar is created by the MFC framework.
If I want to specify the initial directory in the open file dialog box, I have to set it with the member lpstrInitialDir of the OPENFILENAME structure.
My question is how to create the ar CArchive type to be able to call the Serialize method generated by MFC ?
Thanks,
Claude
|
|
|
|
|
Can anybody help me to find detailed information about "Win32_PerfRawData_PerfProc_Thread"
class Win32_PerfRawData_PerfProc_Thread : Win32_PerfRawData
{
string Caption;
uint32 ContextSwitchesPerSec;
string Description;
uint64 ElapsedTime;
uint64 Frequency_Object;
uint64 Frequency_PerfTime;
uint64 Frequency_Sys100NS;
uint32 IDProcess;
uint32 IDThread;
string Name;
uint64 PercentPrivilegedTime;
uint64 PercentProcessorTime;
uint64 PercentUserTime;
uint32 PriorityBase;
uint32 PriorityCurrent;
uint32 StartAddress;
uint32 ThreadState; !!!
uint32 ThreadWaitReason; !!!
uint64 Timestamp_Object;
uint64 Timestamp_PerfTime;
uint64 Timestamp_Sys100NS;
};
Microsoft provides only very limited information about "ThreadState" and "ThreadWaitReason"
I need to find out why paticular thread in other application is waiting.
Thanks
Alex.
|
|
|
|
|
Per MSDN, there are at least 21 values that ThreadWaitReason can have. Likewise, ThreadState can have one of eight values.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hello:
I had to take my work home last night. So, I just copied the entire project and it's folder onto my flash drive. When I got home and opened it up, there were errors about class redefinition. I discovered that AFTER I made changes to a copy I made and received an INCREDIBLE amount of errors.
Now I'm back at work, and I've verified the code builds up just fine. But when I copy the project folder and open up the solution, it again fails to build, saying that I'm redefining classes.
Would anyone know a workaround, besides copying raw code over and creating multiple projects?
Thanks!
|
|
|
|
|
Gosh I feel like blushing.
I was searching around more and decided to try ShowIncludes, to see what the project was doing.
Apparently somehow my includes got out of order. Changed that, watched as it worked fine.
GRR.
|
|
|
|
|
I have done some experimentation.
It appears that there is a bug in Visual C++. Make a copy of a perfectly working project, and it will not compile. It will give you errors about class redefinitions and invalid types.
Now, turn on the Show Included Headers option, under the Advanced C/C++ Project settings. Compiles fine.
Weird.
|
|
|
|
|
Chris Korzeniowski wrote:
Now, turn on the Show Included Headers option, under the Advanced C/C++ Project settings. Compiles fine.
This must not be a Visual Studio v6 issue as I've never seen it.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
When I try to start the program after compiling the code the error message of
Debug assert
File: winocc.cpp
Line 374
start coming up... is there a bug if one use an active x control inside a dialog?
Another query... what is the best way to convert int to string? (std::string)
|
|
|
|
|
If it's MFC that ships with VS.NET 2003, then it's an assert in CWnd::InvokeHelper(). The assert comment says "Not an OLE control (not yet at least)".
Are you perhaps calling any of the control's properties/methods prematurely?
Watertreader wrote:
Another query... what is the best way to convert int to string? (std::string)
std::stringstream is quite sufficient. It works like an ordinary I/O stream, with the exception that it writes to an internal string buffer, to which you can acquire a pointer through the std::stringstream interface.
Another way, which I prefer, is to use CString::Format() which works just like good old sprintf(), but is safer from a security point of view.
There are other ways of converting an int to a string, but these are probably the two most common methods in C++ and/or MFC/ATL projects.
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
thanks for your help! For the winocc.cpp... I am inserting an external control into the code... does it has to be initialised?... the error messge disappear when I use in the RElease mode instead of debug mode
|
|
|
|
|
Watertreader wrote:
I am inserting an external control into the code... does it has to be initialised?...
Yes. ActiveX controls must exist and be registered on the target machine.
Watertreader wrote:
the error messge disappear when I use in the RElease mode instead of debug mode
Compare the compiler/linker options between the two builds. You can do this through the IDE but I find it easier to open the project's .dsp file instead.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
DavidCrow wrote:
Compare the compiler/linker options between the two builds. You can do this through the IDE but I find it easier to open the project's .dsp file instead.
That shouldn't matter when it comes to COM DLLs, as the only memory shared between the DLL and any other DLL/EXE should be owned by the COM heap, and not the individual DLL/EXE.
But maybe MFC is doing sneaky things behind the back, I wouldn't know. I ditched MFC a long time ago.
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
Jörgen Sigvardsson wrote:
That shouldn't matter...
It most certainly does matter. Whether an application is a DLL, EXE, COM or otherwise, if you have different settings other than those that are supposed to be there for the RELEASE and DEBUG builds, you can expect to see differences.
Jörgen Sigvardsson wrote:
...when it comes to COM DLLs, as the only memory shared between the DLL and any other DLL/EXE should be owned by the COM heap, and not the individual DLL/EXE.
I'm not sure what this has to do with checking compiler/linker options.
In the end, this may not even be the problem but it is a possibility that is easy to eliminate.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
DavidCrow wrote:
Whether an application is a DLL, EXE, COM or otherwise, if you have different settings other than those that are supposed to be there for the RELEASE and DEBUG builds, you can expect to see differences.
Only if you're linking statically because...
DavidCrow wrote:
I'm not sure what this has to do with checking compiler/linker options.
IIRC, DLLs get their own heaps, while LIBs don't. I think there's an entry about this on Raymond Chen's blog. I reserve the right to be incorrect.
DavidCrow wrote:
In the end, this may not even be the problem but it is a possibility that is easy to eliminate.
Link errors are easy to find. It's worse when you allocate memory in a DLL, and you free it in another module. The runtime errors are not obvious, as I witnessed last week when my app loaded the wrong DLL. :gah:
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
Jörgen Sigvardsson wrote:
Only if you're linking statically because...
What does linking statically have to do with the subject matter? Go back and re-read this thread. The OP stated that he was seeing differences in his program when going from a RELEASE build to a DEBUG build. My suggestion was to check the compiler/linker options to make sure they are the same. It's very easy to add an option (e.g., /Gr vs. /Gz, or /Zp4 vs. /Zp8) to one and forget to add it to the other.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Perhaps I might be using or linking the lib and dll in a incorrect manner.. but it does not seem to affect the running of the program though....
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
