• Print

Author Topic: $CONSOLE does not work in WINDOWS 8 [support added*]  (Read 652 times)

SMcNeill

  • Hero Member
  • *****
  • Posts: 2414
    • Email
$CONSOLE does not work in WINDOWS 8 [support added*]
« on: October 27, 2012, 03:50:47 PM »
I copied a simple set of code from the wiki:
Code: [Select]
$CONSOLE

_DELAY 4

_CONSOLE OFF

_DELAY 4

_CONSOLE ON

_DEST _CONSOLE

PRINT "Close console window or click main window and press a key!" 

and it does nothing in windows 8.  I thought maybe something was missing from QB64, so I re-downloaded the SDL version and tried it again, and still nothing.   One screen pops up, no console, and nothing anywhere ever says "Close console window or click main window and press a key!"

Whatever command was working to produce a console doesn't seem to work in WIN 8, and since windows 8 is going to be the main OS shipped with new microsoft tablets, phones, computers and stuff, I thought you'd want to know about it.  I don't know of anything else that fails to work in WIN 8 yet, but I'm honestly dreading the hunt.  Bugs can be hard enough to find sometimes, without having to determine that you've done nothing wrong -- that the problem is with the OS and not you. 

/sigh

I wuv Microsoft....   :'(
« Last Edit: April 03, 2013, 09:30:53 PM by Galleon »
http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.
http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

http://bit.ly/DataToDrive - A set of routines to quickly and easily get data to and from the disk.  BI and BM files

mcalkins

  • Hero Member
  • *****
  • Posts: 1269
    • qbasicmichael.com
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #1 on: October 27, 2012, 05:13:25 PM »
I assume that Windows 8 still has cmd.exe? If not, I'd guess you could use PowerShell. Anyway, please try running the .EXE from that code directly from the command prompt. That should prevent the _CONSOLE OFF from doing anything, I think. See if it prints "Close console window or click main window and press a key!"  to the window with the command prompt.

Regards,
Michael
The QBASIC Forum Community: http://www.network54.com/index/10167 Includes off-topic subforums.
QB64 Off-topic subforum: http://qb64offtopic.freeforums.org/

SMcNeill

  • Hero Member
  • *****
  • Posts: 2414
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #2 on: October 27, 2012, 05:22:07 PM »
Nothing. 

It doesn't open a new console window, and it didn't print anything to the cmd window that was already open.

All it does is open a blank screen for a few moments, and then finally say "Press any key to continue" which it always does when it quits running without a SYSTEM command.   No console created, printed to, or used in any way, shape, or form that I can see.  :(
http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.
http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

http://bit.ly/DataToDrive - A set of routines to quickly and easily get data to and from the disk.  BI and BM files

SMcNeill

  • Hero Member
  • *****
  • Posts: 2414
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #3 on: October 27, 2012, 05:54:34 PM »
A couple of screenshots to illustrate the odd behavior:

Code is:
Code: [Select]
PRINT "Junk Here in main Display"


$CONSOLE

_SCREENHIDE
_DEST _CONSOLE
CLS
PRINT "Close console window or click main window and press a key!"
SLEEP
COLOR 15, 0
CLS
SLEEP

Also ran it once with _SCREENHIDE remarked out for comparison.

Maybe a picture of how it looks will help someone sort out what the issue is with console and WIN 8.


Notice how the 1st one prints the Junk on the main screen, but there's no console window popped up anywhere.

Notice how the second one has a Microsoft "stupid attack" (tm) and just tosses us out a white box?  I have no idea what the heck that is.  I can't CLS it to make it change.  I can't change color of it.  I can't print anything in it...  It's like an inverted console that just didn't fully form??

No idea what the issue is, but WIN 8 and $CONSOLE don't work happily together at all. 
http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.
http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

http://bit.ly/DataToDrive - A set of routines to quickly and easily get data to and from the disk.  BI and BM files

mcalkins

  • Hero Member
  • *****
  • Posts: 1269
    • qbasicmichael.com
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #4 on: October 27, 2012, 07:15:44 PM »
Note that QB64 doesn't support the COLOR statement for _DEST _CONSOLE yet.

Please try to run this. It is fairly verbose.

Failure to allocate a console is normal if you already have a console.
Failure to free a console is normal if you don't have one.
In my experience, if AttachConsole fails with error 0x6, all subsequent calls to AllocConsole also fail.
WriteConsoleA and SetConsoleTextAttribute will fail if stdout is redirected.

The most significant thing that the $CONSOLE metacommand does is to tell the linker to set a value in the EXE file's header, which determines whether Windows considers the EXE file to be a console program or not. If so, the program starts with a console, and, if it was launched from a cmd.exe window, cmd will wait for it. Otherwise, the program starts without a console (but can allocate one later), and cmd.exe does not wait for it.

(A console program can create GUI windows (for example, _SCREENSHOW), and a GUI program can create a console (AllocConsole / _CONSOLE ON). The value in the EXE header (set by $CONSOLE) just determines how the program starts out (and whether cmd.exe waits for it), not what it eventually does. (It is the Subsystem field, a word value at offset 68 in the Optional header. In practice, this is at file offset 0xdc in QB64 exe files, a value of 3 for $CONSOLE, otherwise 2.)

I also included GetConsoleProcessList, because QB64 calls this function, (and actually has a buffer overflow vulnerability with regard to it (libqbx requests up to 256 pids, but only allocates space for 250.)).

Because colors might be an issue, I included SetConsoleTextAttribute. For example, {white, blue} should be &h17. You can type &h numbers at the INPUT statement.

Code: [Select]
' you can try this program with and without commenting the $CONSOLE.
' you can also try launching the program both from a command prompt, and a GUI
' program like Explorer.

$CONSOLE

CONST STD_OUTPUT_HANDLE = -11
CONST INVALID_HANDLE_VALUE~%& = -1
CONST ATTACH_PARENT_PROCESS = -1

DECLARE DYNAMIC LIBRARY "kernel32"
 FUNCTION AttachConsole& (BYVAL dwProcessId~&)
 FUNCTION AllocConsole& ()
 FUNCTION FreeConsole& ()
 FUNCTION GetStdHandle~%& (BYVAL nStdHandle~&)
 FUNCTION WriteConsoleA& (BYVAL hConsoleOutput~%&, BYVAL lpBuffer~%&, BYVAL nNumberOfCharsToWrite~&, BYVAL lpNumberOfCharsWritten~%&, BYVAL lpReserved~%&)
 FUNCTION GetConsoleProcessList~& (BYVAL lpdwProcessList~%&, BYVAL dwProcessCount~&)
 FUNCTION SetConsoleTitleA~& (BYVAL lpConsoleTitle~%&)
 FUNCTION SetConsoleTextAttribute& (BYVAL hConsoleOutput~%&, BYVAL wAttributes~%)
 FUNCTION GetLastError~& ()
END DECLARE

DIM hstdout AS _UNSIGNED _OFFSET
DIM num AS _UNSIGNED LONG
DIM pidlist(0 TO 255) AS _UNSIGNED LONG
DIM t AS STRING
DIM crlf AS STRING * 2
crlf = MKI$(&HA0D)

_DELAY 1

PRINT "attempting to get hstdout."
GOSUB updatehandle

t = "1st attempt to print to the console." + crlf
PRINT "This should fail without $CONSOLE, or if output is redirected."
PRINT "WriteConsoleA"
IF 0 = WriteConsoleA(hstdout, _OFFSET(t), LEN(t), _OFFSET(num), 0) THEN
 bad
ELSE
 good: PRINT " Bytes: 0x"; LCASE$(HEX$(num))
END IF

DO
 PRINT
 PRINT "You may only be attached to one console at a time. Expect failure if you try to"
 PRINT "get more than one console."
 PRINT "-- Menu --"
 PRINT "0 --- WriteConsoleA"
 PRINT "1 --- FreeConsole"
 PRINT "2 --- AllocConsole"
 PRINT "3 --- AttachConsole(ATTACH_PARENT_PROCESS)"
 PRINT "4 --- GetConsoleProcessList( , 256)"
 PRINT "5 --- SetConsoleTextAttribute"
 PRINT "ESC --- exit."
 PRINT "Choice? ";
 SLEEP
 t = INKEY$
 PRINT t
 PRINT
 SELECT CASE t
  CASE CHR$(&H1B): EXIT DO
  CASE "0"
   PRINT "WriteConsoleA"
   t = "Hello." + crlf
   IF 0 = WriteConsoleA(hstdout, _OFFSET(t), LEN(t), _OFFSET(num), 0) THEN
    bad
   ELSE
    good: PRINT " Bytes: 0x"; LCASE$(HEX$(num))
   END IF
  CASE "1"
   PRINT "FreeConsole"
   IF 0 = FreeConsole THEN
    bad
   ELSE
    good: PRINT
   END IF
  CASE "2"
   PRINT "AllocConsole"
   IF 0 = AllocConsole THEN
    bad
   ELSE
    good: PRINT
   END IF
   GOSUB updatehandle
  CASE "3"
   PRINT "AttachConsole(ATTACH_PARENT_PROCESS)"
   IF 0 = AttachConsole(ATTACH_PARENT_PROCESS) THEN
    bad
    IF 6 = GetLastError THEN
     COLOR 31, 4
     PRINT "Expect all future calls to AllocConsole to fail.";
     COLOR 7, 0
     PRINT
    END IF
   ELSE
    good: PRINT
   END IF
   GOSUB updatehandle
  CASE "4"
   PRINT "GetConsoleProcessList( , 256)"
   num = GetConsoleProcessList(_OFFSET(pidlist(0)), 1 + UBOUND(pidlist))
   IF 0 = num THEN
    bad
   ELSE
    good: PRINT "Number:"; num
    IF num <= UBOUND(pidlist) THEN
     FOR i = 0 TO num - 1
      PRINT pidlist(i); ",";
     NEXT
     PRINT
    END IF
   END IF
  CASE "5"
   PRINT "(foreground: 1st to 4th lowest bits"
   PRINT "background: 5th to 8th lowest bits)"
   INPUT "colors? ", num
   PRINT "SetConsoleTextAttribute"
   IF 0 = SetConsoleTextAttribute(hstdout, num) THEN
    bad
   ELSE
    good: PRINT
   END IF
 END SELECT
 PRINT
LOOP
SYSTEM

updatehandle:
PRINT "GetStdHandle(STD_OUTPUT_HANDLE)"
hstdout = GetStdHandle(STD_OUTPUT_HANDLE)
IF INVALID_HANDLE_VALUE = hstdout THEN
 bad
ELSE
 good: PRINT " Handle: 0x"; LCASE$(HEX$(hstdout))
END IF

t = "console title" + CHR$(0)
PRINT "SetConsoleTitleA"
IF 0 = SetConsoleTitleA(_OFFSET(t)) THEN
 bad
ELSE
 good: PRINT
END IF
RETURN

SUB bad
COLOR 15, 4
PRINT "Failed.";
COLOR 7, 0
PRINT " Error: 0x"; LCASE$(HEX$(GetLastError))
END SUB

SUB good
COLOR 15, 1
PRINT "Succeeded.";
COLOR 7, 0
END SUB

P.S. I'm guessing they probably changed the default colors for console windows.

If the above program works correctly, then my guess is that the problem might be in the way that QB64 uses fopen or freopen.

P.S. Please remember to check underneath whichever window is on top. Sometimes one window will be almost directly over another.
« Last Edit: October 27, 2012, 07:52:02 PM by mcalkins »
The QBASIC Forum Community: http://www.network54.com/index/10167 Includes off-topic subforums.
QB64 Off-topic subforum: http://qb64offtopic.freeforums.org/

iamdenteddisk

  • Hero Member
  • *****
  • Posts: 2737
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #5 on: October 27, 2012, 08:13:58 PM »
perhaps I will pause on adding console output to my projects till a solution is had. or just better save under a second file name to keep both versions..

HACKER

  • Limited Member
  • Hero Member
  • *
  • Posts: 761
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #6 on: October 28, 2012, 07:35:56 AM »
This is Only a Start with Windows!-Blinds!-Shutters! 8

Everyone make sure you don't get Rid of your XP Windows 7 Etc.

It's a Shame QB64 could not be 100% Independent!? and not Need Windows Etc. Maybe back to DOS  H :)

SMcNeill

  • Hero Member
  • *****
  • Posts: 2414
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #7 on: October 28, 2012, 09:56:16 AM »
Michael, that's an interesting set of code, and it generates all sorts of feedback.  :)

When I first start it up, it tells me:

GetStdHandle(STD_OUTPUT_HANDLE)
Succeeded.  Handle 0x0
SetConsoleTitleA
Failed.  Error: 0x6
This should fail without $CONSOLE, or if output is redirected.
WriteConsoleA
Failed.  Error 0x6

At this point, there is no console pop-up.

Clicking:

#1 -- Succeeded

#2 -- a console window pops up.  If I click the X and close the console, BOTH windows close - the console and your program.

If I click #3, it fails and I get a blinking red flash text that tells me to expect all future calls to fail.

#4 fails.  Error 0x6

#5 fails.  Error 0x6

**************

If I use option #2 to make the console pop-up, then:

option #0 succeeds and prints "Hello." to the console.  Success 0x8.
option #3 still fails.
option #4 succeeds.  Number 1 -- and then a 3604 ,   on the line below it
option #2 fails.  Error 0x5  (I already have a console I guess)
option #1 succeeds and closes the console.

*****************

I'm not certain what magic you're working in the code (I haven't had time to look through it yet - it's family time with the daughter), but AllocConsole makes a console -- makes the first console I've seen so far while running WIN 8.

It looks like you're on the way to sorting out the issue fairly quickly.  Got to admit, I'm impressed!  It's hard to debug a system you're not even running yourself, and having to rely on user feedback.  My hat's off to ya, good sir!  :D

http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.
http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

http://bit.ly/DataToDrive - A set of routines to quickly and easily get data to and from the disk.  BI and BM files

mcalkins

  • Hero Member
  • *****
  • Posts: 1269
    • qbasicmichael.com
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #8 on: October 28, 2012, 12:04:42 PM »
Thanks for trying it, and thanks for the words. However, please don't expect too much from me.

Quote
GetStdHandle(STD_OUTPUT_HANDLE)
Succeeded.  Handle 0x0
SetConsoleTitleA
Failed.  Error: 0x6
This should fail without $CONSOLE, or if output is redirected.
WriteConsoleA
Failed.  Error 0x6

That is exactly what should happen if the $CONSOLE is commented out. Had you commented out the $CONSOLE? If not, that's a problem. Perhaps Windows is no longer respecting the Subsystem field, or perhaps mingw is failing to set it.

(Despite GetStdHandle "succeeding", 0 is not a valid handle. It means that there is no standard output handle at that time.)

Quote
#1 -- Succeeded

You hadn't allocated a console, but FreeConsole succeeded? On XP, FreeConsole fails with error 0x57 unless you have a console...

So, if I understand you correctly, SetConsoleTitle fails, but FreeConsole succeeds? You didn't allocate a console in between? I don't know what to make of that. If you had a console, SetConsoleTitle shouldn't have failed. If you didn't have a console, FreeConsole should have failed. I assume that if you try FreeConsole twice in a row, the second one would definitely fail?

Quote
If I click the X and close the console, BOTH windows close - the console and your program.

That's normal. (There is a way to prevent that.)

Quote
If I click #3, it fails and I get a blinking red flash text that tells me to expect all future calls to fail.

AttachConsole(ATTACH_PARENT_PROCESS) will succeed only if you don't already have a console, and if your parent is still alive and does have a console.

On XP, if you already have a console, it fails with error 5. If you don't have a console, but your parent doesn't either, it fails with error 6.

Quote
option #4 succeeds.  Number 1 -- and then a 3604 ,   on the line below it

That means that 1 process (yours) is attached to your console, and has a PID of 3604. (You can view PIDs in ProcessExplorer or Task Manager.)

If you are sharing the console with other processes, for example, your parent, then the number should be more than 1. QB64 uses this to detect if the console is being shared, that is, whether a $CONSOLE program was launched from a console program, like cmd.exe.

There's no magic. It's just using the API. Either Windows "8" broke something that QB64 relies on, or there is some fragility or misbehavior in QB64 that works in XP to "7", but not in "8".

QB64 (libqbx) uses AllocConsole and FreeConsole for _CONSOLE ON and _CONSOLE OFF. (Also, for the SHELL statement.)

However, QB64 does not directly use GetStdHandle, WriteConsoleA, or WriteFile for the console output. (There are references to GetStdHandle, but they are all commented out.) (It does use WriteFile for other things.) Instead, it uses std::cout for console output. I was thinking that it used freopen for the handles, but as far as I can tell, that's commented out also. I'm not sure what it is doing. I would think that there should be something in sub__console for the handles also, but there isn't... I intend to investigate...

Regards,
Michael
The QBASIC Forum Community: http://www.network54.com/index/10167 Includes off-topic subforums.
QB64 Off-topic subforum: http://qb64offtopic.freeforums.org/

SMcNeill

  • Hero Member
  • *****
  • Posts: 2414
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #9 on: October 28, 2012, 01:12:52 PM »
Quote from: mcalkins on October 28, 2012, 12:04:42 PM
That is exactly what should happen if the $CONSOLE is commented out. Had you commented out the $CONSOLE? If not, that's a problem. Perhaps Windows is no longer respecting the Subsystem field, or perhaps mingw is failing to set it.

(Despite GetStdHandle "succeeding", 0 is not a valid handle. It means that there is no standard output handle at that time.)

$CONSOLE was active when I ran all the tests above.  I haven't had a chance to try it with $CONSOLE commented out yet.

http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.
http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

http://bit.ly/DataToDrive - A set of routines to quickly and easily get data to and from the disk.  BI and BM files

mcalkins

  • Hero Member
  • *****
  • Posts: 1269
    • qbasicmichael.com
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #10 on: October 28, 2012, 02:31:44 PM »
No rush. Family time is important.

Just to rule out some sort of issue of mingw not setting the Subsystem field: (I don't think that this is the problem, but it doesn't hurt to check.)

When you get a chance, you might try qb64.exe with the -x switch from a command prompt. (qb64.exe was precompiled as a console program...)

Also, please try this program with and without the $CONSOLE commented:

Code: [Select]
$CONSOLE

DECLARE DYNAMIC LIBRARY "kernel32"
 FUNCTION GetModuleHandleW~%& (BYVAL lpModuleName~%&)
END DECLARE
DECLARE CUSTOMTYPE LIBRARY
 SUB memcpy (BYVAL dest~%&, BYVAL src~%&, BYVAL count~%&) 'discard return value
END DECLARE

DIM p AS _UNSIGNED _OFFSET
DIM d AS _UNSIGNED LONG
DIM w AS _UNSIGNED INTEGER

p = GetModuleHandleW(0)
PRINT "image base: 0x"; LCASE$(HEX$(p))
memcpy _OFFSET(d), p + &H3C, LEN(d)
PRINT "file offset of PE signature: 0x"; LCASE$(HEX$(d))
p = p + d
memcpy _OFFSET(d), p, LEN(d)
IF d <> CVI("PE") THEN PRINT "could not find PE signature.": END
memcpy _OFFSET(w), p + 4 + 20 + 68, LEN(w)

PRINT LCASE$(HEX$(w))
SELECT CASE w
 CASE 2: PRINT "GUI"
 CASE 3: PRINT "Console"
 CASE ELSE: PRINT "other"
END SELECT
END

(I used memcpy instead of my peekpoke routines so that it would be self contained.)



More generally, I think that QB64 might be confusing the concept of stdin/stdout/stderr with consoles. They are actually separate things, and I would prefer to see QB64 treat them separately. Perhaps have a _DEST _STDOUT which would be distinct from _DEST _CONSOLE. (Or perhaps have dedicated file numbers so that you could for example PRINT #_STDOUT, "whatever" without even changing the _DEST target.) (In the future, QB64 could add things like COLOR and LOCATE for consoles, but stdout should always be thought of as just a simple text stream. A console is always a console, whereas stdout might be going to a console, a file, or a pipe.)

P.S. Also, in general, most programs would never need to change their standard handles. You either get the default standard handles which point to a console, or you inherit handles given to you by your parent, in which case, your parent probably wants you to use them. _DEST _CONSOLE should always use a real console (CreateFile "CONOUT$"), and PRINT #_STDOUT (GetStdHandle) would be used for a text output stream that is intended to go to whatever the parent wanted. Likewise for input. (The parent can redirect the child's handles by using the STARTUPINFO structure with CreateProcess. So, I'm having a hard time thinking of good reasons to ever use SetStdHandle.)

Regards,
Michael
« Last Edit: October 28, 2012, 03:11:59 PM by mcalkins »
The QBASIC Forum Community: http://www.network54.com/index/10167 Includes off-topic subforums.
QB64 Off-topic subforum: http://qb64offtopic.freeforums.org/

Clippy

  • Hero Member
  • *****
  • Posts: 16442
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #11 on: October 28, 2012, 05:02:14 PM »
Well what I would like to see is a way to tell QB64 you want to use a CONSOLE, but not right away. Perhaps the $CONSOLE metacommand could do that, but not display it until _CONSOLE ON is used.

Otherwise we have to shut it OFF immediately. It should not show up until we actually need it. Sometimes it doesn't go away right away either even if OFF is immediately after it!

I notice it sometimes just running the IDE even when I don't use it. On my XP and now on W7. I find that annoying too...

QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

SMcNeill

  • Hero Member
  • *****
  • Posts: 2414
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #12 on: October 28, 2012, 07:28:52 PM »
Quote from: mcalkins on October 28, 2012, 02:31:44 PM
Also, please try this program with and without the $CONSOLE commented:

Code: [Select]
$CONSOLE

DECLARE DYNAMIC LIBRARY "kernel32"
 FUNCTION GetModuleHandleW~%& (BYVAL lpModuleName~%&)
END DECLARE
DECLARE CUSTOMTYPE LIBRARY
 SUB memcpy (BYVAL dest~%&, BYVAL src~%&, BYVAL count~%&) 'discard return value
END DECLARE

DIM p AS _UNSIGNED _OFFSET
DIM d AS _UNSIGNED LONG
DIM w AS _UNSIGNED INTEGER

p = GetModuleHandleW(0)
PRINT "image base: 0x"; LCASE$(HEX$(p))
memcpy _OFFSET(d), p + &H3C, LEN(d)
PRINT "file offset of PE signature: 0x"; LCASE$(HEX$(d))
p = p + d
memcpy _OFFSET(d), p, LEN(d)
IF d <> CVI("PE") THEN PRINT "could not find PE signature.": END
memcpy _OFFSET(w), p + 4 + 20 + 68, LEN(w)

PRINT LCASE$(HEX$(w))
SELECT CASE w
 CASE 2: PRINT "GUI"
 CASE 3: PRINT "Console"
 CASE ELSE: PRINT "other"
END SELECT
END


In this case, I get the exact same results no matter if $CONSOLE is active or remarked out:
image base: 0x400000
file offset of PE signature:0x80
2
GUI

The console is never created.
http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.
http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

http://bit.ly/DataToDrive - A set of routines to quickly and easily get data to and from the disk.  BI and BM files

SMcNeill

  • Hero Member
  • *****
  • Posts: 2414
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #13 on: October 28, 2012, 07:38:12 PM »
I *CAN* get a console to pop up, with this little bit of code:

Code: [Select]
$CONSOLE

DECLARE DYNAMIC LIBRARY "kernel32"
    FUNCTION AllocConsole& ()
END DECLARE

x = AllocConsole

That's all it takes to make a console.  _CONSOLE OFF doesn't work with it though.

I tried a slight modification by adding this to the bottom of it.
Code: [Select]
PRINT x
_DEST _CONSOLE
PRINT "Hello"

x = 1 shows in the main program window, but the "Hello" never shows up in console window.
http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.
http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

http://bit.ly/DataToDrive - A set of routines to quickly and easily get data to and from the disk.  BI and BM files

mcalkins

  • Hero Member
  • *****
  • Posts: 1269
    • qbasicmichael.com
    • Email
Re: $CONSOLE does not work in WINDOWS 8
« Reply #14 on: October 28, 2012, 10:36:47 PM »
Quote
In this case, I get the exact same results no matter if $CONSOLE is active or remarked out:
[...]
2
GUI

Bingo...

I've compared recompile.bat with and without $CONSOLE. Either way, it has "-mwindows", but with $CONSOLE, it also has "-mconsole" before "-mwindows". I'm not a fan of MinGW/GCC documentation, but some searching on the internet reveals:

http://old.nabble.com/Re%3A--mwindows-and---Wl,subsystem,windows-p22770535.html

I'm going to guess that if you edit the recompile.bat of a console program to replace:
-mwindows
with:
-lgdi32 -lcomdlg32
and run it, that the program would perform as expected.

Please try that with the program that checks the PE header.

If it works then, a more permanent fix might be to change, in qb64.bas:

Code: [Select]
    IF Console THEN x = INSTR(a$, "-mwindows"): a$ = LEFT$(a$, x - 1) + "-mconsole " + RIGHT$(a$, LEN(a$) - x + 1)

    IF inline_DATA = 0 THEN
        'add data.o?
        IF DataOffset THEN
            x = INSTR(a$, "-L.\l")
            IF x THEN
                x = x + 4
                a$ = LEFT$(a$, x) + " " + tmpdir2$ + "data.o" + RIGHT$(a$, LEN(a$) - x)
            END IF
        END IF
    END IF

    'add custom libraries
    'mylib$="..\..\"+x$+".lib"
    IF LEN(mylib$) THEN
        x = INSTR(a$, "-mwindows")
        IF x THEN
            x = x + 8
            a$ = LEFT$(a$, x) + " " + mylib$ + RIGHT$(a$, LEN(a$) - x)
        END IF
    END IF

to:

Code: [Select]
    IF inline_DATA = 0 THEN
        'add data.o?
        IF DataOffset THEN
            x = INSTR(a$, "-L.\l")
            IF x THEN
                x = x + 4
                a$ = LEFT$(a$, x) + " " + tmpdir2$ + "data.o" + RIGHT$(a$, LEN(a$) - x)
            END IF
        END IF
    END IF

    'add custom libraries
    'mylib$="..\..\"+x$+".lib"
    IF LEN(mylib$) THEN
        x = INSTR(a$, "-mwindows")
        IF x THEN
            x = x + 8
            a$ = LEFT$(a$, x) + " " + mylib$ + RIGHT$(a$, LEN(a$) - x)
        END IF
    END IF

IF Console THEN x = INSTR(a$, "-mwindows"): a$ = LEFT$(a$, x - 1) + "-mconsole -lgdi32 -lcomdlg32 " + MID$(a$, x + 10)

Remember that QB64 is itself a $CONSOLE program (because of -x), so if you compile it on the windows "8" computer, you might want to recompile it again so that it benefits from the fix.



Quote
I tried a slight modification by adding this to the bottom of it.
[...]
x = 1 shows in the main program window, but the "Hello" never shows up in console window.

You would probably need to freopen stdout (which I believe is pointer to a FILE structure maintained by the CRT), which would be impractical to do directly from QB64. A small header could be used.

http://www.qb64.net/forum/index.php?topic=3795.msg38313#msg38313

However, I don't recommend doing that.

Regards,
Michael
« Last Edit: October 28, 2012, 10:47:03 PM by mcalkins »
The QBASIC Forum Community: http://www.network54.com/index/10167 Includes off-topic subforums.
QB64 Off-topic subforum: http://qb64offtopic.freeforums.org/

  • Print