Program too big to fit in memory
-
I have a Managed C++ Windows Forms program that I'm compiling in Visual Studio 2003. When I try to run it, it tells me "Program too big to fit in memory" in a command prompt. Does anyone know why it would even pop up with a command prompt window when this is a Windows application? Secondly, why would I get this error? Sources from google tell me that usually, this has to do with a corrupt installer issue, but this is not an installer at all. Thanks.
-
I have a Managed C++ Windows Forms program that I'm compiling in Visual Studio 2003. When I try to run it, it tells me "Program too big to fit in memory" in a command prompt. Does anyone know why it would even pop up with a command prompt window when this is a Windows application? Secondly, why would I get this error? Sources from google tell me that usually, this has to do with a corrupt installer issue, but this is not an installer at all. Thanks.
I think I might've found the issue. I believe it lies with trying to reference an unmanaged lib (not compiled with managed extensions in C++), from a project that is compiled into a managed executable (managed extensions enabled). From what I've read, it seems to me (so far) that the only way to do this is to use a .dll and PInvoke, but is there any way to simply use a .lib?
-
I think I might've found the issue. I believe it lies with trying to reference an unmanaged lib (not compiled with managed extensions in C++), from a project that is compiled into a managed executable (managed extensions enabled). From what I've read, it seems to me (so far) that the only way to do this is to use a .dll and PInvoke, but is there any way to simply use a .lib?
The lib should work fine. C++/CLI lets you call code in static and dynamic libraries without p/invoke. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
The lib should work fine. C++/CLI lets you call code in static and dynamic libraries without p/invoke. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Hi Mark, Thanks for the info, however, here's the problem. The first time I do a build, it always fails with a LNK1000 error where essentially, VC7's link.exe throws some kind of exception. If I try to build it again, it succeeds. Always. The only problem is, that the generated executable is invalid. At first, I couldn't figure out what was wrong. Then, because I suspected some kind of dependency issue, I ran depends.exe on the generated executable, and it told me that the PE header was invalid (or something to that effect). Then, that was where I suspected the managed/unmanaged stuff. I should also note that I have a solution of 3 projects, 1 of which is the executable (managed), 1 of which is a static library (managed), 1 of which is a static library (unmanaged). If I remove the unmanaged static library from its reference list or dependency chain, building the executable complains about linker errors (as expected, since I have not defined the symbols). As soon as I add the unmanaged static library, I get the LNK1000.
-
Hi Mark, Thanks for the info, however, here's the problem. The first time I do a build, it always fails with a LNK1000 error where essentially, VC7's link.exe throws some kind of exception. If I try to build it again, it succeeds. Always. The only problem is, that the generated executable is invalid. At first, I couldn't figure out what was wrong. Then, because I suspected some kind of dependency issue, I ran depends.exe on the generated executable, and it told me that the PE header was invalid (or something to that effect). Then, that was where I suspected the managed/unmanaged stuff. I should also note that I have a solution of 3 projects, 1 of which is the executable (managed), 1 of which is a static library (managed), 1 of which is a static library (unmanaged). If I remove the unmanaged static library from its reference list or dependency chain, building the executable complains about linker errors (as expected, since I have not defined the symbols). As soon as I add the unmanaged static library, I get the LNK1000.
Cyrilix wrote:
1 of which is a static library (managed)
I'm not sure how well that's going to work, nor can I find any solid confirmation one way or the other. Binding of managed types in a library is done at the assembly level. I'm not sure how well the linker's going to handle that. A managed class library (DLL) is the appropriate way to make a managed library (even if it has native code in it as well).
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
I have a Managed C++ Windows Forms program that I'm compiling in Visual Studio 2003. When I try to run it, it tells me "Program too big to fit in memory" in a command prompt. Does anyone know why it would even pop up with a command prompt window when this is a Windows application? Secondly, why would I get this error? Sources from google tell me that usually, this has to do with a corrupt installer issue, but this is not an installer at all. Thanks.
Cyrilix wrote:
I'm compiling in Visual Studio 2003
I definitely recommend moving to at least VS 2005 (VC 8) any way you can, as soon as you can, before investing a lot of time in code that is incompatible with newer/future C++ compilers. With VC8+, you get the actual C++/CLI language instead of the Managed Extensions you are using with VC7, which aren't supported anymore (there's a compiler switch to allow it...for now). The Managed Extensions for C++ syntax is deprecated. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Cyrilix wrote:
1 of which is a static library (managed)
I'm not sure how well that's going to work, nor can I find any solid confirmation one way or the other. Binding of managed types in a library is done at the assembly level. I'm not sure how well the linker's going to handle that. A managed class library (DLL) is the appropriate way to make a managed library (even if it has native code in it as well).
Mark Salsbery Microsoft MVP - Visual C++ :java:
Well, the way it works is that I have a managed static lib that contains my __gc classes. Then, I have an unmanaged static lib depending on and using the managed static lib that contains regular (non __gc) classes, which is sort of my interface to the native world. I've been able to use this interface with other classes from native code without problem. Then, I have a Winforms app which depends on that native interface. Now that I think of this, it doesn't really make sense as to why I'm doing it this way. I'm sort of going Managed->Unmanaged->Managed... might as well see if I can cut out the middle layer.
-
Cyrilix wrote:
I'm compiling in Visual Studio 2003
I definitely recommend moving to at least VS 2005 (VC 8) any way you can, as soon as you can, before investing a lot of time in code that is incompatible with newer/future C++ compilers. With VC8+, you get the actual C++/CLI language instead of the Managed Extensions you are using with VC7, which aren't supported anymore (there's a compiler switch to allow it...for now). The Managed Extensions for C++ syntax is deprecated. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: