http://bugs.winehq.org/show_bug.cgi?id=10919
Summary: GetLargestConsoleWindowSize() should not return hard coded constants Product: Wine Version: 0.9.51. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-console AssignedTo: wine-bugs@winehq.org ReportedBy: reijo.sund@helsinki.fi
Created an attachment (id=9840) --> (http://bugs.winehq.org/attachment.cgi?id=9840) sizepro.c - A source demonstrating the problem and a solution in terms of APIs
----------------------------------------------------------------------
MSDN library includes sample code for console applications (http://msdn2.microsoft.com/en-us/library/aa263818.aspx). The source is available at: http://www.helsinki.fi/~sund/console_vs6.zip . The source compiles easily with winelib after --cuiexe transformations with winemaker.
The examples 14 and 32 deal with the GetLargestConsoleWindowSize() function. The problem is that the current implementation in Wine returns hard coded constants (X=80, Y=24) for the maximum size. This causes problems for applications that have followed the conventions of sample code, because it "prevents" the resizing of console window to bigger than "maximum".
In principle, the window size could be changed manually by using properties dialog, but that is an "ugly" solution. Another "ugly" solution would be to change the hard coded constants to bigger values in Wine implementation.
A better solution would be to actually implement the required functionality. I have attached a source (sizepro.c, compiles with 'winegcc -o sizepro.exe sizepro.c') that demonstrates the problem and infers the maximum console window size in relation to current resolution and font.
I also tried to implement the corresponding functionality to Wine, and attached the source for the improved function (kernel32_console_ getlargestconsolewindowssize.c). That works fine for me, but I'm not sure whether it follows the conventions of Wine (or how to deal with strange __i386__ definitions without duplicating the code). So, I wonder if someone else more familiar with Wine development could check it out and derive an adequate patch.