I agree that this requirement is weird, specificallly as you are using cin and cout, which are also part of the STL, and internally do use dynamic container classes! Not to mention that for the purpose of writing and reading simple char arrays, cin and cout are hopelessly inefficient, you'd be better served with puts() and _getch().
Since you don't know the length of the input in advance, the only way to ensure you have a sufficiently large buffer is using a container that dynamically resizes itself. If you don't want to use std::string, or other string classes like CString, then I suppose using std::vector is out of the question as well? If that is so, you have to implement a dynamical container yourself. I don't see why anyone would want you to waste time on that though, unless it is for homework.
Anyway, what you need to do is
1. use or implement your own dynamical container, such as std::vector
2. make a loop to read the input, using _getch() to read individual characters
3. for each character, check whether it belongs to the input, or indocates the end of input; if input, store it in your dynamical container.
Also, at the end of the program, don't forget to release the memory that you allocated for your dynamical container. std::vector or std::string will do that for you, but if you have your own class, you need to take care of it yourself.
The getcwd function will "get the current working directory" which is not always the same as the directory the process executable is residing in. There are many standard API calls that will change the current working directory of your process. In fact... the CreateProcess function itself has the option of starting your process in an arbitrary working directory.
In InitInstance(), member m_pszExeName is your image name. So, use SearchPath() on the result of CString(m_pszExeName) + CString(".exe"). Use the lpFilePart parameter of the call to isolate the path from the file name.
I made a custom CButton::DrawItem() so that I could draw some buttons the way I want them. One of the things I'm doing with it, is making the button "pin-able" to the right side of the parent dialog's (cwnd) display rectangle (using it both as a child to a CDialog and another CButton, in different cases). It seems though, that when a window is maximized, then restored, the restore doesn't call CButton::DrawItem(), leaving my button in the middle of nowhere. If I track the messages, it doesn't seem the framework ever asks the CButton object (or the parent dialog for that matter) to redraw when it is restored.
Seems like maximize and restore are treated differently in the framework. Has anyone seen this before or know how to deal with it?
I was trying to have the CButton automatically reposition himself within the DrawItem(), that doesn't work too well though (because of the order that the DrawItem() calls are made in) and because WM_SIZE handles some sizing changes different than others. So it was just easier to reposition the button from within the parent if it needs to move (from OnSize() with SetWindowPos() rather than Invalidate()).