|
Rajesh R Subramanian wrote: Sorry for calling you an idiot and thanks for taking the time to explain. [Smile]
[Shameless] After the upgradation of CP, You can re-vote on any post, just in case, FYI. [Red faced] [/Shameless]
Don't worry about it. I was(am?) an idiot, I just reject spineless. 
Post re-voted.(5)
seeya!
|
|
|
|
|
Manasi D wrote: How to Run UNIX based EXE [MKS] through Shell in VC++ application
not sure, but wouldn't having a cygwin help ?
otherwise, i'm not sure at all this can be done...
|
|
|
|
|
Cygwin is just an emulator. The OP wants to run a UNIX binary under a windows machine. Cygwin (or nothing else) can run a native UNIX app on Windows. Talk about doing the impossible.
And that is an urgent query, if you haven't noticed it yet.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Rajesh R Subramanian wrote: Cygwin (or nothing else) can run a native UNIX app on Windows. Talk about doing the impossible.
For the record I am not the guy who voted you down. 
But I wanted to say that you are absolutely incorrect. Compilers simply generate machine code and Unix/Linux ELF binaries are nothing more than a file format. The instructions inside are still x86 instructions. I have done many experiments executing simple ELF binaries on Windows as have many others before me. For simple commandline/shell ELF binaries all you need to do is implement some of the missing libc and/or ncurses functions. It certainly becomes more difficult when the complexity of the ELF is increased. For example non-static ELF binaries which are loading many shared objects can be extremely difficult to load in Windows.
At any rate I just wanted to point out that you should never say something is impossible. There are many talented researchers who read this forum who just might do the impossible.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: The instructions inside are still x86 instructions. I have done many experiments executing simple ELF binaries on Windows as have many others before me. For simple commandline/shell ELF binaries all you need to do is implement some of the missing libc and/or ncurses functions. It certainly becomes more difficult when the complexity of the ELF is increased.
Believe me or not, I hesitated a moment to choose between "impossible" and "next to impossible". Because I've heard this hack, only from an old professor of mine. While you say that you've experimented on similar stuff, I can guess your age and experience. So, my respect for you has gone up by two notches. And thanks for the inputs; that's a lot interesting. I'll probably read up on that in free time.
[ADD]And needless to say, I know that you won't be the one down-voting. [/ADD]
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
modified on Friday, May 9, 2008 11:30 AM
|
|
|
|
|
I agree with you i know wine [^]on linux runs native win32 code even directX code. Rajesh knows i won't vote down.
|
|
|
|
|
Rajkumar R wrote: I agree with you i know wine [^]on linux runs native win32 code
I was wondering about the converse part of it. Running UNIX code - rather UNIX binaries on Windows. 
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
I mean the possiblility. that David was discussing although reverse.
|
|
|
|
|
That should be fantastic man. What do you think? I'm going to give that a little try at my free time.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
you should. good luck.
Now there are tools like linux virtual machines running on windows that can do run native codes, some colleagues use it.
|
|
|
|
|
Just as WINE runs windows execs in linux, LINE runs linux execs in windows.
There's also lina, but that requires sources be recompiled (changing what, I can only guess)
|
|
|
|
|
That must make a fantastic read. My Sunday will be spent on this, I'm afraid.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Manasi D wrote: Int lnSts =_spawnl(_P_NOWAIT,"SHELL.exe","SHELL.exe","-Lc Target.EXE",NULL);
If you are wanting something a little more modern that _spawnl(), see here.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I have an MFC application whose onok and onkcancel method have been disable. Also I have overidden the esc and return keystroked. This MFC application calls another application B thru a createprocess method and aits via WaitForSingleObject until this application B quits. At this point I would like to quit my application. How do I self destroy my dialog. Please provide the exact API call. I used postmessage without luck.
|
|
|
|
|
Try EndDialog(0);
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Rajesh, prefer using the Enumerators rather than their values.
in brief, use IDC_CANCEL instead of 0 
|
|
|
|
|
toxcct wrote: in brief, use IDC_CANCEL instead of 0
You mean IDCANCEL? The framework will use IDCANCEL as the return value if the dialog is closed by clicking the Cancel button or the X button or pressing Alt+F4 (and as a result the OnCancel() being triggered).
Now, I don't think there is any valid reason for me to go out of my way and use IDCANCEL as my return value (which is equal to 2 and not 0), for the very reason that my app was not closed because of a cancel event. I might want to return 0 (which might mean everything went on fine) or, say return 24 (something like - the user chose to pause the process in between and close the dialog).
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
man, this is not a chat, it's a forum !!!
if you can't wait 10 minutes that i reply to your question, then you're definitely not at the right place to ask.
so as i was saying, and as Rajesh confirmed, EndDialog(IDC_CANCEL)[^] is a good solution.
modified on Friday, May 9, 2008 9:28 AM
|
|
|
|
|
Below is the code the control is not coming after dlg.DoModal();
if (!CreateProcess(NULL, /* No module name (use command line). */
theApp.m_lpCmdLine, /* Command line. */
NULL, /* Process handle not inheritable. */
NULL, /* Thread handle not inheritable. */
FALSE, /* Set handle inheritance to FALSE. */
CREATE_NO_WINDOW, /* Do not display console window */
NULL, /* Use parent's environment block. */
NULL, /* Use parent's starting directory. */
&si, /* Pointer to STARTUPINFO structure. */
&pi)) /* Pointer to PROCESS_INFORMATION structure. */
status = GetLastError();
CProgressActivityDlg dlg;
m_pMainWnd = &dlg;
//INT_PTR nResponse =
dlg.DoModal();
//if (nResponse == IDOK)
//{
// TODO: Place code here to handle when the dialog is
// dismissed with OK
//}
//else if (nResponse == IDCANCEL)
//{
// TODO: Place code here to handle when the dialog is
// dismissed with Cancel
//}
MessageBox(NULL, _T("Before loop"), _T("Test"), MB_OK);
WaitForSingleObject(pi.hProcess, INFINITE);
MessageBox(NULL, _T("Out of loop"), _T("Test"), MB_OK);
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
PostMessageW(dlg.GetSafeHwnd(), WM_CLOSE ,0, 0);
// Since the dialog has been closed, return FALSE so that we exit the
// application, rather than start the application's message pump.
AfxGetMainWnd()->PostMessage(WM_CLOSE, 0, 0);
return FALSE;
|
|
|
|
|
So the problem is to get the control out of dlg.DoModal(); somehow is it possible to do so usisng the modal dialog I have created. what is the alternative
|
|
|
|
|
tom groezer wrote: the problem is to get the control out of dlg.DoModal()
You'd have to send/post a message to the dialog. When the dialog responds to
the message, it can call CDialog::EndDialog().
The problem is you need another thread to post the message - or the message has to
come from the other process.
An alternative is to use a modeless dialog, but if you sit and wait on the UI thread
for the other process to end, your dialog will become unresponsive.
Best bet....use a worker thread to wait on the other process
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi there.
I've got a bit of a weird one here. I'm writing a pair of compression/decompression programs for a varsity assignment and there is something odd happening in the transmission of integers. Basically, the spec is that they must be stored big endian so I wrote these:
bool writeintbigendian ( FILE * file, int number )<br />
{<br />
unsigned char *c = ( unsigned char * ) &number;<br />
<br />
for ( short i = sizeof ( int ) - 1; i > -1; i-- )<br />
{<br />
if ( fputc ( c[i], file ) ==EOF )<br />
return false;<br />
}<br />
<br />
return true;<br />
};<br />
<br />
int readintbigendian ( FILE * file )<br />
{<br />
int readInt = 0;<br />
unsigned char * c = ( unsigned char * ) &readInt;<br />
<br />
for ( short i = sizeof ( int )-1; i > -1; i--)<br />
{<br />
c[i] = (unsigned char) fgetc(file); <br />
}<br />
<br />
return readInt;<br />
};
Now there is a dictionary of ints that are written out using writeintbigendian and then the ints are read in using readintbigendian to reconstruct it. The process reads in like 42 ints and then bombs out where the value of -230 was supposed to have been written. The reason being because -1 is read instead of -230.
To narrow down the problem, I stopped the debugger in the write section to find out what it was writing. The arguments to fputc are the following in order:
-230 = |255|255|255|26|
when it comes to reading it out using fgetc it ends up with
-1 = |255|255|255|255|
Clearly either the read function is reading the last byte in incorrectly or the write is writing it incorrectly but I can't figure out which. It's certainly not a synching issue either because the previous 42 values all get transmitted fine and there are no other intermediate steps when reading or writing. It's literally going through a for loop on both sides calling the respective functions. Obviously, I'd like to avoid delving into binary formats of files here.
|
|
|
|
|
OK, I've closed the file after it writes the last byte and analysed the binary. It definitely writes |255|255|255|26|. Which means fgetc in readintbigendian is at fault. Is there some Windows sideffect I'm unaware of?
|
|
|
|
|
I don't think its issue with read, you just try to open file write -230 close it, open read and close and check, may be you are not reading from correct offset.
|
|
|
|
|
Yes, that would be the obvious conclusion but the fact is 42 items previous to that are being read correctly, so the offsets are clearly correctly synched.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
