Win 11 console

[dodicat]

Looks like you can easily change to the old console now:
Open the start menu on the taskbar (the 4 blue squares)
settings
system
For developers
In the terminal drop down list choose Windows Console Host.

Tester code:

Code: Select all

#include "windows.bi"
Shell "color f0"
Sub changefontsize(w As Long, h As Long,ftype As String="consolas")
    Dim As  _CONSOLE_FONT_INFOEX  x
    With x
        .cbsize=Sizeof(_CONSOLE_FONT_INFOEX)
        .nfont=0
        .dwfontsize=Type(w,h)
        .fontfamily=0
        .fontweight=100
        .facename=ftype
    End With
    setcurrentconsolefontex(GetStdHandle(STD_OUTPUT_HANDLE),1, @x )
End Sub

Sub changeconsolesize(cols As Long,lines As Long)
    Shell "MODE CON: COLS="+Str(cols)+ "LINES="+Str(lines)
End Sub

Sub getfontsize(x as _CONSOLE_FONT_INFOEX)
        x.cbsize=Sizeof(_CONSOLE_FONT_INFOEX)
    getcurrentconsolefontex(GetStdHandle(STD_OUTPUT_HANDLE),false, @x )
End Sub

dim as _CONSOLE_FONT_INFOEX f

getfontsize(f)
print "Initial font size =  ";f.dwFontSize.x;" by";f.dwFontSize.y 

'====================
Print "Press a key"
Sleep


changefontsize(13,28)

Print "new font size this session = 13 by 28"

Dim As String asci
For n As Long=0 To 255
    asci+=Chr(n) 'create a string
Next

Locate 10
Print asci


Print "Now change the console size again,  press a key"
Sleep
Cls
changefontsize(15,30)
changeconsolesize(50,4)

Print "New console size = COLS=50 LINES=4"
Print "Font size 15 by 30"
Print "Press a key to end . . . "
Sleep

 

You can just as easily switch back if you prefer Windows Terminal.

[srvaldez]

Hi dodicat
yes, I mentioned that when UEZ was trying to programmatically detect the type of terminal and change it at runtime but there was no success
you can also change the terminal that will be attached to the program via a shortcut to the program and editing the appropriate setting, but I Prefer the method that you mentioned.
the new terminal is too buggy to use although some people like it, it's puzzling.
<edit> in 64-bit you could launch conhost.exe via the shell command but apparently there's no 32-bit conhost.exe

[caseih]

I like the new terminal because it is a "real" terminal finally with proper terminal emulation. And it's much better for cutting and pasting command-line text. Been a long time coming. MS even ships ssh with Windows now. About time. Just wish they'd ship rsync too. And vim. haha.

[srvaldez]

I thought I would give the terminal another try but it's just as buggy as last I used it, that was about a year ago
if you change the the launch size to 65 rows and after saving run a program that prints many lines of text, the terminal window size will be 65 rows but text will only be printed on the first 30 rows and there's no scrolling available so you can't scroll up to see the first lines of text

[UEZ]

Hi dodicat
yes, I mentioned that when UEZ was trying to programmatically detect the type of terminal and change it at runtime but there was no success
you can also change the terminal that will be attached to the program via a shortcut to the program and editing the appropriate setting, but I Prefer the method that you mentioned.
the new terminal is too buggy to use although some people like it, it's puzzling.
<edit> in 64-bit you could launch conhost.exe via the shell command but apparently there's no 32-bit conhost.exe

You can detect the cmd console by checking the parent process. The tricky part is to start the own exe in the cmd app.
If you have a look to the Radio Station player I wrote, you can see how I solved it.

[dodicat]

Yes, thanks srvaldez, I did see your post but I cannot get For developers and terminal from privacy settings here, I have to go through settings/system which goes to show that Win 11 does not seem consistent through continents.
Thanks caseih
Although perhaps changing font sizes or gdi stuff in the terminal is not usual, the fb print statement is, and it does not seem compatible with the new Win 11 terminal inasmuch as it does not scroll.
Printf is OK, also C++ cout<< and pascal writeln are OK (scrollable on the terminal).

So the PRINT statement, excellent as it is (has been) for generality, has met it's nemesis in Win 11 terminal, and of course PRINT(ing) is the most important statement for any console application.
It maybe needs looked at for further Windows, and I have a feeling that will not be an easy task for the developers.
Luckily we can use printf or puts in freebasic just now as a scrollable alternative.
Also the win 10 console is good for copying and pasting, I find the Win 11 terminal just useless, and I have the latest Win 11 update done:
Microsoft Windows [Version 10.0.22621.2861]
(c) Microsoft Corporation. All rights reserved.
So I must be missing something (caseih).

[srvaldez]

dodicat, at first that's where the setting was but then they changed it to the way now is

[caseih]

I thought I would give the terminal another try but it's just as buggy as last I used it, that was about a year ago
if you change the the launch size to 65 rows and after saving run a program that prints many lines of text, the terminal window size will be 65 rows but text will only be printed on the first 30 rows and there's no scrolling available so you can't scroll up to see the first lines of text

I certainly do not see this issue here, on Windows 10 or 11. Scroll-back buffer seems to be thousands of lines, regardless of the starting size or how I resize it, perhaps limited only by memory. I'm sure there are bugs but it's as functional as any terminal I've used on any OS. Traditional, native win32 console apps were of course designed for conhost, not terminal, so I'm sure there are impedance mismatches trying to direct their output into terminal. I'm sure as apps begin purposely targeting terminal, you'll find their behavior will be better. The few native console apps I have on hand ran flawlessly, including the Vim text editor.

[caseih]

I'm sure changes will be needed in the FB runtime to properly support terminal. FB works great with Linux, so there's no reason it can't do the same on Windows with the Terminal. On Linux, as long as you don't use LOCATE, output can buffered and scrolled back to. I have not had the opportunity to test this in Windows, but from what you say, I can expect some issues there.

Also remember there are different ways of interacting with a text-mode terminal, be it conhost or terminal. One way is to take over the "screen" and write anywhere on it. Think an editor, IDE, word processor, spreadsheet. These types of output will not end up in the scroll-back buffer, nor can you cut and paste their output using the terminal hotkeys (although on some terminal emulators there are other ways of forcibly grabbing and pasting text).

The other way of using a terminal or console is to simply output lines of text, which do go into the buffer and are scroll-able.

Note that conhost let you cut and paste in either type of application, because it was just character-based selecting, and worked on the final output that was being displayed. Potentially useful, but I found it frustrating and limiting.

In short Terminal is not "buggy" as you say, but rather I think you're just encountering the effects of how the programs you are running use the screen. If FB runtime behavior needs to change to be more like Linux to support Terminal then that is not a bug in Terminal, but a feature request for FB. EDIT: I read that the venerable ncurses library (which FB on Linux uses), now supports the Windows Terminal, so it might be possible for FB for Windows to use it to better support the Terminal, like it does on Linux.

[srvaldez]

caseih you may be right, geany launches the cmd like this: cmd.exe /Q /C %c
I searched for almost an hour to find command line options for the terminal that would be equivalent to those options but all I found was a ton of "split" and "pane" but nothing that would answer my question

[UEZ]

Extract of Radio Station Player code how to restart own compiled program in CMD directly without changing the default settings (Windows only).

Code: Select all

'Coded by UEZ build 2023-12-18
#Ifdef __fb_64bit__
	#Inclib "gdiplus"
	#Include Once "win\gdiplus-c.bi"
#Else
	#Include Once "win\gdiplus.bi"
	Using Gdiplus
#Endif
#Include "win\tlhelp32.bi"
#Include "win\commctrl.bi"

Function _WinAPI_TerminateProcess(iPID As Integer, iExitCode As Integer = 0, bInheritHandle As Boolean = FALSE) As Boolean
	Dim As Long dwDesiredAccess = PROCESS_TERMINATE
	Dim As Handle hProcess = OpenProcess(dwDesiredAccess, bInheritHandle, iPID)
	If hProcess = Null Then Return False
	TerminateProcess(hProcess, iExitCode)
	CloseHandle(hProcess)
	Return True
End Function

Function _WinAPI_IsOSx86() As Boolean 'https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getnativesysteminfo?redirectedfrom=MSDN
	Dim As SYSTEM_INFO lpSystemInfo
	GetNativeSystemInfo(@lpSystemInfo)
	Return lpSystemInfo.wProcessorArchitecture = PROCESSOR_ARCHITECTURE_INTEL
End Function

Function _WinAPI_GetProcessName(iPid As DWORD) As String
	Dim As HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, iPid)
	If hSnapshot = 0 Then Return ""
	Dim As PROCESSENTRY32W tPROCESSENTRY32W
	tPROCESSENTRY32W.dwSize = Sizeof(PROCESSENTRY32W)
	Process32FirstW(hSnapshot, @tPROCESSENTRY32W)
	While True
		If tPROCESSENTRY32W.th32ProcessID = iPid Then Exit While
		If Process32NextW(hSnapshot,  @tPROCESSENTRY32W) = 0 Then Exit While
	Wend
	CloseHandle(hSnapshot)
	Return tPROCESSENTRY32W.szExeFile
End Function

Function _WinAPI_GetParentProcess(iPID As Integer = 0) As Integer
	Dim As DWORD pid = Iif(iPID = 0, GetCurrentProcessId(), iPID), pid_parent = 0
	Dim As HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0)
	Dim As PROCESSENTRY32 tPROCESSENTRY32
	tPROCESSENTRY32.dwSize = Sizeof(tPROCESSENTRY32)
	Process32First(hSnapshot, @tPROCESSENTRY32)
	While TRUE
		If tPROCESSENTRY32.th32ProcessID = pid Then
			pid_parent = tPROCESSENTRY32.th32ParentProcessID
			Exit While
		End If
		Process32Next(hSnapshot, @tPROCESSENTRY32)
	Wend
	CloseHandle(hSnapshot)
	Return pid_parent
End Function

'check if exe is started in PowerShell cli
If _WinAPI_GetProcessName(_WinAPI_GetParentProcess()) = "powershell.exe" Then 
	? "Doesn't work properly in the PowerShell environment! Please start it in CMD instead!"
	End
Endif

Declare Function RtlGetVersion Lib "NtDll.dll" Alias "RtlGetVersion" (OsVersionInformation As RTL_OSVERSIONINFOW) As Long

Dim As String sArguments = " "

Dim As Any Ptr hConsole = GetConsoleWindow()
Dim Shared As RTL_OSVERSIONINFOW OS
OS.dwOSVersionInfoSize = Sizeof(RTL_OSVERSIONINFOW)
RtlGetVersion(OS)

Dim As Wstring * 4096 sClassname
GetClassNameW(hConsole, @sClassname, 4096)

If (SendMessageW(hConsole, WM_GETICON, Iif(OS.dwBuildNumber < 9200, 1, 0), 0) = 0 And sClassname = "PseudoConsoleWindow") And Command(1) <> "restart" Then 'restart app in CMD window
	#ifdef __FB_64BIT__
		Shell("conhost.exe """ &  Command(0) & """ restart" & sArguments)
	#Else
		If _WinAPI_IsOSx86() = False Then
			Dim As String sConhost = "C:\Windows\Sysnative\conhost.exe"
            Shell(sConhost & " """ & Command(0) & """ restart" & sArguments)
		Else
			Shell("conhost.exe """ &  Command(0) & """ restart" & sArguments)
		Endif
	#endif 
	FreeConsole()
	End 1000
Endif

If Command(1) = "restart" Then
	Dim As String exeName = Mid(Command(0), Instrrev(Command(0), "/") + 1, Len(Command(0)))
	Dim As Ubyte countParentPIDs = 0
	Dim As Integer iPID, parentPID = _WinAPI_GetParentProcess()
	While True
		iPID = _WinAPI_GetParentProcess(parentPID)
		If _WinAPI_GetProcessName(iPID) <> "cmd.exe" Then 
			parentPID = iPID
			countParentPIDs += 1
			If countParentPIDs > 5 Then Exit While
		Else
			_WinAPI_TerminateProcess(iPID, 0, True)
			Exit While
		Endif
	Wend
Endif


'Your CMD code starts from line below

Shell "color f0"
Sub changefontsize(w As Long, h As Long,ftype As String="consolas")
    Dim As  _CONSOLE_FONT_INFOEX  x
    With x
        .cbsize=Sizeof(_CONSOLE_FONT_INFOEX)
        .nfont=0
        .dwfontsize=Type(w,h)
        .fontfamily=0
        .fontweight=100
        .facename=ftype
    End With
    setcurrentconsolefontex(GetStdHandle(STD_OUTPUT_HANDLE),1, @x )
End Sub

Sub changeconsolesize(cols As Long,lines As Long)
    Shell "MODE CON: COLS="+Str(cols)+ "LINES="+Str(lines)
End Sub

Sub getfontsize(x as _CONSOLE_FONT_INFOEX)
        x.cbsize=Sizeof(_CONSOLE_FONT_INFOEX)
    getcurrentconsolefontex(GetStdHandle(STD_OUTPUT_HANDLE),false, @x )
End Sub

dim as _CONSOLE_FONT_INFOEX f

getfontsize(f)
print "Initial font size =  ";f.dwFontSize.x;" by";f.dwFontSize.y 

'====================
Print "Press a key"
Sleep


changefontsize(13,28)

Print "new font size this session = 13 by 28"

Dim As String asci
For n As Long=0 To 255
    asci+=Chr(n) 'create a string
Next

Locate 10
Print asci


Print "Now change the console size again,  press a key"
Sleep
Cls
changefontsize(15,30)
changeconsolesize(50,4)

Print "New console size = COLS=50 LINES=4"
Print "Font size 15 by 30"
Print "Press a key to end . . . "
Sleep

[srvaldez]

thanks a million UEZ
@caseih
yesterday when I first tested the new Windows terminal I could have sworn that it would print on all 65 rows but then I picked another color scheme and it was then that the problem manifested, I tried my best to reset to the default but no luck.
well today I restored my system from backup and the terminal did print on all 65 rows until I chose the light theme then the problem resurfaced, now tell me that it's not buggy
to reiterate, after setting the rows to 65 and tested somewhat ok, I only chose the light theme, nothing else.
about somewhat ok, it printed on all 65 rows but you could not scroll up to any line above that, that is you have 65 lines and no more

[srvaldez]

@UEZ
unfortunately all I get is (program exited with code: 1000)

[caseih]

caseih you may be right, geany launches the cmd like this: cmd.exe /Q /C %c
I searched for almost an hour to find command line options for the terminal that would be equivalent to those options but all I found was a ton of "split" and "pane" but nothing that would answer my question

cmd.exe is just a console application. Whether it runs in Terminal under conhost by default depends on how you've set your Windows defaults, if what I read above is correct.

[adeyblue]

Dim As String sConhost = _WinAPI_FindFile("C:\Windows\WinSxS\amd64_microsoft-onecore-console-host-core_*", "conhost.exe")

In 32-bit apps you can use sysnative to access the 64-bit system32 folder without it being redirected to syswow64, like
C:\Windows\Sysnative\conhost.exe
It is only recognised by 32-bit apps on 64-bit Windows though, so you still need different things for 32- and 64-.

You can also just turn off the the system32 -> syswow64 thing temporarily so you can use system32 to mean actual system32 in all cases with
Wow64DisableWow64FsRedirection
It does affect things like dll loading though, so when it's off, all the LoadLibrary of windows dlls will fail as it'll be trying to load the 64-bit dlls.