Author Topic: Compliant 64-bit compiling  (Read 11030 times)

0 Members and 1 Guest are viewing this topic.

Charles Pegge

  • Guest
Re: Compliant 64-bit compiling
« Reply #15 on: April 29, 2018, 06:31:17 PM »
Gentlemen,

I think the best solution in these negative number situations is to specify the type:

if a=dword -1 then

The alternative is to use an int or dword variable.

my test code:
Code: [Select]
$ filename "t.exe"
uses rtl64
uses corewin
uses console
string f
do
  print cr "filename "
  f=ltrim rtrim input
  if not f then exit do
  dword a=GetFileAttributes f
  'dword n=-1'INVALID_FILE_ATTRIBUTES
  'if a=n then
  if a=dword -1 then
    print "invalid file/folder name" cr
  else
    print "attrib code " a cr
  end if
  'invalid=-1 folders=16 files=32
loop
« Last Edit: April 29, 2018, 06:51:38 PM by Charles Pegge »

Arnold

  • Guest
Re: Compliant 64-bit compiling
« Reply #16 on: May 07, 2018, 09:17:27 AM »
Hi Charles,

this is a nice little demo which I ported to Oxygenbasic using notify statements. I must use:
dword TCN_SELCHANGE= -551
dword TCN_SELCHANGING= -552

to compile it correctly in Win64. This solution seems to work at any rate. But I am not sure if I am a bit obtuse and overlook all the time the same thing?

Roland

Code: [Select]
'https://msdn.microsoft.com/de-de/library/windows/desktop/hh298367(v=vs.85).aspx

$ filename "win_tabnotify.exe"

'uses rtl32
'uses rtl64

uses WinUtil
'uses console

#autodim off

indexbase 0

% WC_TABCONTROL="SysTabControl32"
% WC_STATIC="Static"
% ICC_TAB_CLASSES = 8
% TCIF_TEXT=1
% TCIF_IMAGE=2
% TCM_INSERTITEM=4871
% TCM_GETCURSEL=4875
dword TCN_SELCHANGE= -551
dword TCN_SELCHANGING= -552
% SWP_SHOWWINDOW=64
% HWND_TOP=0

type TCITEM
  int   mask,dwState,dwStateMask
  char* pszText
  int   cchTextMax,iImage
  sys   lParam
end type
typedef TCITEM TC_ITEM


% DAYS_IN_WEEK 7
string day[]={"Sun","Mon","Tue","Wed","Thu","Fri","Sat"}

' Initialize common controls.
INITCOMMONCONTROLSEXt icex
    icex.dwSize = sizeof(INITCOMMONCONTROLSEX)
    icex.dwICC = ICC_TAB_CLASSES
    InitCommonControlsEx(&icex)

sys hInstance=inst
MainWindow 480,360,WS_OVERLAPPEDWINDOW


function WndProc(sys hwnd, uMsg, wParam, lParam) as sys callback
    static sys hwndTab, hwndStatic

    select uMsg
   
    case WM_CREATE
        ' Get the dimensions of the parent window's client area, and
        ' create a tab control child window of that size.
        RECT rcClient
        TCITEM tie
   
        GetClientRect(hwnd, &rcClient)
        hwndTab = CreateWindowEx(0,WC_TABCONTROL, "",
             WS_CHILD | WS_CLIPSIBLINGS | WS_VISIBLE,
             0, 0, rcClient.right, rcClient.bottom,
             hwnd, null, hInstance, null)
        if (hwndTab = null) then
           mbox "Create Tab Control failed"
           return null
        end if
        ' Add tabs for each day of the week.
        tie.mask = TCIF_TEXT | TCIF_IMAGE
        tie.iImage = -1 
 
        int i
        for i = 0 to <DAYS_IN_WEEK
           ' Load the day string
           tie.pszText=day[i]
           if SendMessage(hwndTab,TCM_INSERTITEM,i, @tie) = -1 then
             mbox "InsertItem Tab failed"
             DestroyWindow(hwndTab)
             return null
           end if
        next i

        ' Creates a child window (a static control) to occupy the tab control's display area.
        ' hwndTab - handle of the tab control.
        hwndStatic = CreateWindowEx(0,WC_STATIC, "",
                          WS_CHILD | WS_VISIBLE | WS_BORDER,
                          100, 100, 100, 100,        ' Position and dimensions; example only.
                          hwndTab, null, hInstance,    ' g_hInst is the global instance handle
                          null) 
        SendMessage(hwndStatic, WM_SETTEXT, 0, strptr day[0]) 'Sunday
       
        case WM_SIZE
            ' Handles the WM_SIZE message for the main window by resizing the tab control.
            ' hwndTab - handle of the tab control.
            ' lParam - the lParam parameter of the WM_SIZE message.
'           RECT rc
            ' Resize the tab control to fit the client are of main window.
'           SetWindowPos(hwndTab, HWND_TOP, 0, 0, GET_X_LPARAM(lParam), GET_Y_LPARAM(lParam), SWP_SHOWWINDOW)
            int x=loword(lParam) : int y=hiword(lParam)
            SetWindowPos(hwndTab, HWND_TOP, 0,0, x,y, SWP_SHOWWINDOW)

        case WM_NOTIFY
            ' Handles notifications from the tab control, as follows:
            ' TCN_SELCHANGING - always returns FALSE to allow the user to select a different tab. 
            ' TCN_SELCHANGE - loads a string resource and displays it in a
            '      static control on the selected tab.
            ' hwndTab - handle of the tab control.
            ' lParam - the lParam parameter of the WM_NOTIFY message.
            NMHDR pnmhdr at lParam
            select pnmhdr.code

            case TCN_SELCHANGING
                    ' Return FALSE to allow the selection to change.
                    return FALSE

            case TCN_SELCHANGE               
''                  int iPage = TabCtrl_GetCurSel(hwndTab)
                    int iPage = SendMessage(hwndTab, TCM_GETCURSEL, 0,0)                   
                    SendMessage(hwndStatic, WM_SETTEXT, 0, strptr day[iPage])
 
            end select
            return TRUE

       
        case WM_CLOSE
            DestroyWindow(hwnd)
       
        case WM_DESTROY
            PostQuitMessage(0)
       
        case else
            return DefWindowProc(hwnd, uMsg, wParam, lParam)
           
    end select
   
    return 0
end function

Charles Pegge

  • Guest
Re: Compliant 64-bit compiling
« Reply #17 on: May 07, 2018, 05:54:12 PM »
Thanks, Roland.

I'm trying a tiny adjustment to O2, so that integer cases are evaluated as 32bit max. This fixes the negative equate case problem, and I don't think it will have any practical disadvantage.

Arnold

  • Guest
Re: Compliant 64-bit compiling
« Reply #18 on: October 08, 2018, 12:49:54 AM »
Hi Charles,

running this code snippet in Win32 there is no problem. Running in Win64 the app will crash at some point if I only use the Enter key. If I comment out line 11 or add a statement: if len(ans)=0 then there is no problem in Win64 neither. I only report this result because of the differenc to Win32 behaviour. Maybe with your current version of O2 this is already fixed.

Roland

Code: [Select]
$ filename "TestInput.exe"

uses rtl64

uses console

cls
printl "Do wish to see the answer? (Y/N)"
string ans=input()

ans=ltrim rtrim ans     'Enter in Win64 does not work

if lcase(ans) = "y" then
  printl "Your answer is Yes"
else
  printl "Your answer is not Yes"
end if

printl "Enter ... " : waitkey     

Charles Pegge

  • Guest
Re: Compliant 64-bit compiling
« Reply #19 on: October 08, 2018, 03:18:17 AM »
Hi Roland,

There were no problems running this code using my current o2. Could you try it again with the console.inc below.


Arnold

  • Guest
Re: Compliant 64-bit compiling
« Reply #20 on: October 08, 2018, 03:39:14 AM »
Using the modified console.inc I get the same result if I only use the Enter key. But as it will work with the current o2 build this is no big deal.

Arnold

  • Guest
Re: Compliant 64-bit compiling
« Reply #21 on: June 23, 2019, 12:14:30 AM »
Hi Charles,

in the release of June 2019 there is \examples\WinGUI\Autosizing\Demo7Dlg.o2bas. Changing the TabPages does not work any more. Could these lines be modified?

line 17/18:

% TCN_SELCHANGE= dword  -551
% TCN_SELCHANGING= dword-552

to

% TCN_SELCHANGE= -551
% TCN_SELCHANGING= -552

I used the other form as an auxiliary construct to run the demo with older Oxygenbasic releases in Win 64-bit. With the new release this is not necessary any more and I must admit that the other form looks a bit strange anyway.

Roland

Charles Pegge

  • Guest
Re: Compliant 64-bit compiling
« Reply #22 on: June 23, 2019, 01:23:50 AM »
Fixed. Thanks Roland. That is the only one among the examples. But I've discovered a few more 'dword -' instances to clean up.

Arnold

  • Guest
Re: Compliant 64-bit compiling
« Reply #23 on: August 15, 2019, 05:21:45 AM »
Hi Charles,

using version 0.2.6 I found this problem when I try to load a non existing file:

Code: [Select]
$ filename "LoadFile.exe"
'uses rtl32
'uses rtl64

string s
string fname="aFile.txt"  'does not exist
getfile fname, s

's=ltrim rtrim(s)          'without comment will crash in 64-bit mode
if len(s)=0 then print "Error loading " + fname else print "Loaded File " fname

Line 9 does not work in 64-bit mode and the app crashes. Using a comment will work in 32-bit mode and in 64-bit mode.

Roland

Charles Pegge

  • Guest
Re: Compliant 64-bit compiling
« Reply #24 on: August 15, 2019, 07:14:27 AM »
Thanks Roland,

Null strings (with null ponter) not properly processed.  This will be fixed in RTL64.inc, for both ltrim and rtrim

test code:
Code: [Select]
$filename "o.exe"
uses rtl64
string s
print ltrim(rtrim(s))
print "ok"

Arnold

  • Guest
Re: Compliant 64-bit compiling
« Reply #25 on: December 11, 2019, 03:26:04 AM »
Hi Charles, Mike,

I would like to refer to \projectsB\Console\Printf.o2bas. The demo works in 32-bit and failes in 64-bit mode. I tried this code snippet:

Code: [Select]
$ Filename "Test_iob.exe"
'uses rtl32
'uses rtl64

uses corewin
'uses console

'sys _iob = __p__iob()
'print _iob

print __p__iob()

Must __p__iob() be applied differently in 64-bit mode or is it not available in this mode? The structure FILE is used in stdio.h of tcc also, and printf works with tcc in 64-bit too. But it seems there is another approach used. I simply do not understand this piece of code in stdio.h:

#ifdef _WIN64
  _CRTIMP FILE *__cdecl __iob_func(void);
#else
#ifdef _MSVCRT_
extern FILE _iob[];     /* A pointer to an array of FILE */
#define __iob_func()    (_iob)

Is there a solution to run the different printf functions of msvcrt.dll in 64-bit also? It would be a pity if it is not possible in O2.

Roland

Mike Lobanovsky

  • Guest
Re: Compliant 64-bit compiling
« Reply #26 on: December 11, 2019, 04:31:01 AM »
Roland,

Though both C and Win32 provide access to consoles to read from or write to, their console systems are not interchangeable.

For instance, C provides STDIN, STDOUT and STDERR consoles that are regarded as pure files, and printf()/fprintf()/etc. functions, to manage their text. On the other hand, Win32 provides indirect access to its consoles through their read/write buffers that bear no resemblance to files/streams.

Therefore, changing the mini-/nanoscheme printing technique from C to O2 Win32-based printing seemed to me too much error-prone PITA. A 32-bit msvcrt.dll runtime is supposed to provide several exported functions that return an array of pointers to STDIN/-OUT/-ERR "files" usable for printing with C file handling functions. Unfortunately, some of the exports turned out to be mere stubs, and __p__iob() was the only one function whose return I was able to use in Oxygen as valid pointers to the console "files".

64-bit C STDIN/-OUT/-ERR "file" access seems to be a little different from 32 bits, and it wasn't actual for me at the time I worked on the 32-bit oxy-/nanoscheme code.

If you feel you can spare your time on switching from C-style printing over to Oxygen-style Win32 printing, you are free to modify the oxyscheme code (it's Public Domain anyway) as you like. But I can't guarantee it won't have any unexpected side effects on the oxyscheme code that's yet unproven functioning in the latest Oxygene builds.

Arnold

  • Guest
Re: Compliant 64-bit compiling
« Reply #27 on: December 11, 2019, 07:52:36 AM »
Hi MIke,

probably I can apply sprintf in combination with print and get the same result. Some functions of msvcrt.dll seem to work quite nice in Win64. Unfortunately I have not yet found some more extensive documentation about this dll, many links seem to be broken.

Roland

Charles Pegge

  • Guest
Re: Compliant 64-bit compiling
« Reply #28 on: December 12, 2019, 02:31:10 AM »
Hi Roland,

In 64bit mode, variadic params 1..4 are passed in cpu registers regardless of float types. Therefore a prototype is required to declare the variadic types:

uses corewin
...
! sprintf (char *s,*f,...) at @sprintf


Code: [Select]
'10:12 12/12/2019
'float variadic params are passed in cpu in 64bit mode
$filename "o.exe"
uses rtl64
uses corewin
char c[64] 'string buffer
double v1=123
extern
 'create an overlay of sprintf with variadic prototype
! sprintf (char *s,*f,...) at @sprintf
#show sprintf (c,"%4.2f",v1) '123.00
print c
« Last Edit: December 12, 2019, 02:39:16 AM by Charles Pegge »

Arnold

  • Guest
Re: Compliant 64-bit compiling
« Reply #29 on: December 13, 2019, 02:37:42 AM »
Hi Charles,

this solution of declaring sprintf is indeed brilliant. Now something like this will be possible:

Code: [Select]
char strg
int a = 10, b = 38, double c
c = a / b

sprintf(strg, "Value of Pi = %15.10f" + chr(10) + "Division of %d by %d is: %15.10f", pi, a, b, c)
print strg   

I see that I will need 'extern' for compiling to 64-bit. Is there also a need for 'end extern' or is this not necessary?

Roland
« Last Edit: December 13, 2019, 02:58:50 AM by Arnold »