http://bugs.winehq.com/show_bug.cgi?id=1406
Summary: 16-BIT VB 3.0 APP -- "NOT ENOUGH SPACE FOR ENVIROMENT" Product: Wine Version: CVS Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P3 Component: wine-resources AssignedTo: wine-bugs@winehq.com ReportedBy: marc_lavergne@yahoo.com
I have been hoping to see this working with baseline WINE releases for about 2 years now. It's not a high priority but it's a curious problem. One particular application I have errors out with a "NOT ENOUGH SPACE FOR ENVIRONMENT" message on startup. I do not have the source code for this application.
The application itself is a 16-bit VB 3.0 application used to access an online database. The header indicates it's an MZ type executable and the imports show it's based on VBRUN300. There's an NE marker in the header as well. Another application with exactly the same header (but a different app nonetheless) works just fine.
The WINE trace shows the following as the cause:
err:local:LOCAL_GetBlock not enough space in local heap 0dc7 for 140 bytes
Now, all that said, if I uncomment the FIXMEs int memory/local.c and prevent the call from returning 0 in LOCAL_GetBlock, it works fine (for a while at least). So, I guess the question is, why are the FIXME's in that function still FIXME's after all this time. I'm sure there is a reason for not uncommenting this code but if anybody could shed light on this, or get the FIXME's accepted it would be really appreciated.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://bugs.winehq.com/show_bug.cgi?id=1406. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.