Announcement

Collapse
No announcement yet.

Good read on 64bit

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Good read on 64bit

    GOOD READ ON 64BIT
    https://stackoverflow.com/questions/...e-32-or-64-bit

  • #2
    another good read on 64bit

    Writing 64-bit programs
    by Jeremy Gordon -
    https://www.godevtool.com/GoasmHelp/64bits.htm#easy

    Comment


    • #3
      https://www.godevtool.com/GoasmHelp/64bits.htm#easy

      This file is intended for those interested in writing 64-bit programs for the AMD64 and EM64T processors running on x64 (64-bit Windows), using GoAsm (assembler), GoRC (resource compiler) and GoLink (linker). It may also be of interest to those writing 64-bit assembler programs for Windows using other tools

      What is the the relevance of that link to PowerBASIC for WIndows (which is the sub-forum you have posted in)?

      Rules reminder once again:

      Rule 1: This forum is for discussing and supporting the PowerBASIC product line.

      Comment


      • #4
        Thanks so much James.

        I have used 64bit programs that can shell execute 32bit Powerbasic programs, and they worked very well.
        In this context, it is good to have another programing language that can still utilize the essence of Powerbasic
        programs.

        Comment


        • #5
          thanks Anne

          Comment


          • #6
            i am sorry but i think being loyal to 32 bit powerbasic is great
            my worry is that Microsoft my drop 32bit support in Lou of all 64bit like they did with 16bit
            my old powerbasic would not work when they dropped 16bit powerbasic sent me updated compilers
            at no charge.this is forum.powerbasic.com. this is powerbasic related for the furtherance of powerbasic
            i thank every one
            again powerbasic compilers are the greatest with asm and win32api
            again thanks

            Comment


            • #7
              Long ago when Bob was still alive I asked him about posting bits and pieces of MASM code and he said he did not care as MASM and assemblers in general were not trying to compete with PowerBASIC. I would be far more concerned with people trying to sneak in other basic dialects as this does compete with PowerBASIC. If somebody wished to wax lyrical about other basic dialects, they should do so at the support facilities of that dialect, not in the PowerBASIC forum.

              Now for anyone who does write 64 bit code, any flavour, there is a trick where you can use a memory mapped file to transfer data from a 32 bit PB app to a 64 bit app and while it is limited to 32 bit limits for each data transfer, if the computer has enough memory, you can make multiple data transfers that are stored in the 64 bit app. I don't personally need it as I mainly work in 64 bit MASM but its a technique that could be useful to folks who develop in 32 bit PowerBASIC. 32 bit can work with just under 2 gig in a single block so you can store multiple blocks of that size in a 64 bit app and get it back on call using standard Windows messaging AND memory mapped files.
              hutch at movsd dot com
              The MASM Forum

              www.masm32.com

              Comment


              • #8
                ..drop 32bit support in [lieu] of all 64bit like they did with 16bit my old powerbasic would not work when they dropped 16bit

                I think you may be prematurely worried. Win/32 in the form of NT 3.51 was released May 30, 1995. Support for 16-bit programs died officially with the ''end of support" for Windows XP which was April 6 2014. Windows/64 was born in either 2003 or 2005 (conflicting data) with Windows XP/64.

                You will certainly have enough time to move your apps off of 32-bit when whatever comes after 64-bit is released.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  Originally posted by Michael Mattias View Post


                  I think you may be prematurely worried. Win/32 in the form of NT 3.51 was released May 30, 1995. Support for 16-bit programs died officially with the ''end of support" for Windows XP which was April 6 2014. Windows/64 was born in either 2003 or 2005 (conflicting data) with Windows XP/64.

                  You will certainly have enough time to move your apps off of 32-bit when whatever comes after 64-bit is released.
                  Indeed!

                  Why worry about Win32 till Win128 comes out? (or Win-Quantum if they skip 128 bit)


                  Dale

                  Comment


                  • #10
                    Originally posted by Dale Yarker View Post
                    Indeed!

                    Why worry about Win32 till Win128 comes out? (or Win-Quantum if they skip 128 bit)

                    Especially considering how MS are encouraging wider adoption of the Win32 APIs:

                    https://blogs.windows.com/windowsdev...ore-languages/

                    Comment


                    • #11
                      An interesting read and the approach should be useful to the mentioned languages as well as a few others that may not normally be able to access the Win32 API. Almost all of the API was translated to 64 bit and they come very close to identical performance to the 32 bit versions and this has been useful in that you can still use the old WIN32.HLP file as reference for the core API functions that have been around since the middle 1990s.
                      hutch at movsd dot com
                      The MASM Forum

                      www.masm32.com

                      Comment


                      • #12
                        > Especially considering how MS are encouraging wider adoption of the Win32 APIs:

                        When MS speaks about Win32 APIs it means both 32 and 64 bit.
                        Forum: http://www.jose.it-berater.org/smfforum/index.php

                        Comment


                        • #13
                          you can still use the old WIN32.HLP file as reference
                          You may use the online doc without registering or paying any fees.

                          I know, I know.. "that means I have to be online."

                          Methinks (I have precisely zero scientific evidence, just a Mark-I Gut Feel) that "being online" is going to be a lot like being in the atmosphere in the not-too-distant future.
                          Michael Mattias
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            Originally posted by Steve Hutchesson View Post
                            ... you can still use the old WIN32.HLP file as reference for the core API functions that have been around since the middle 1990s.
                            I'd say this is largely true, as long as you stuck with with the C/C++ typedefs. But in other languages, this can get tricky. For example, LPARAM and WPARAM are not what you'd infer them to be from the original documentation back then. In 64-bit Windows, LPARAM is not a long (32-bit) integer, and WPARAM is not a word (16-bit). LPARAM is now defined as LONG_PTR (a signed 32-bit or 64-bit integer, depending on platform) and WPARAM is defined as UINT_PTR (and unsigned 32-bit or 64-bit integer, depending on platform).

                            Similarly, most callback arguments which have traditionally been LONG or DWORD are now defined as LONG_PTR or DWORD_PTR. Just something to be aware of when referring to old documentation that originated with 16-bit and 32-bit Windows.

                            Mike Stefanik
                            sockettools.com

                            Comment


                            • #15
                              Similarly, most callback arguments which have traditionally been LONG or DWORD are now defined as LONG_PTR or DWORD_PTR. Just something to be aware of when referring to old documentation that originated with 16-bit and 32-bit Windows.
                              Are those addresses as opposed to the values they [ WPARAM, LPARAM] are today?

                              Michael Mattias
                              Tal Systems (retired)
                              Port Washington WI USA
                              [email protected]
                              http://www.talsystems.com

                              Comment


                              • #16
                                Anyone who has written Win32 for a long time is familiar with translating old Microsoft C/C++ into their own language format. Doing the same in 64 bit is no big deal to do as long as you know your normal data types for the executable file format you are using, 32 or 64 bit and your main choice is between DWORD and QWORD. 32 bit is simpler as 64 bit is a hybrid of 32 and 64 bit data, a RECT structure in 64 bit is still 4 x 32 bit values and there are enough others to be aware of.

                                SetWindowLong() becomes SetWindowLongPtr() and there are a few others but in the main, you simply use the function name and 64 bit data so SendMessage() has 4 x QWORD members, a WndProc() has 4 x QWORD members and so on. The old WIN32.HLP is useful because it handles the core Win API, if you want later stuff, MSDN.
                                hutch at movsd dot com
                                The MASM Forum

                                www.masm32.com

                                Comment


                                • #17
                                  Originally posted by Michael Mattias View Post

                                  Are those addresses as opposed to the values they [ WPARAM, LPARAM] are today?
                                  The answer is "maybe". In C/C++ you can cast any address into a an integer value, and cast any integer value to an address (pointer). The Win32 API takes advantage of this by allowing those kinds of values with callbacks where the parameter may be an address or it may be just a value that has some meaning specific to your application or a particular control.

                                  And then you have handles, which may actually be pointers, or they may be some opaque value which is an index into a table of structures or an array of pointers. That's where you can have the weirdness of some 64-bit handles where all bits are significant, and other handles where only the lower 32 bits are significant for portability.
                                  Mike Stefanik
                                  sockettools.com

                                  Comment


                                  • #18
                                    Address v Values example.to clarify question and hopefully eliminate ambiguous answer:

                                    WPARAM = LONG (Win32) or UINT_PTR (Win 64, post #14) ; LPARAM= LONG (Win32) or LONG_PTR (Post 14)

                                    When MSG= WM_COMMAND, does WParam = (Lowrd)/Control ID (HiWRD) notificaton code or address of some composite of these values? Is Lparam value of handle to sending control or address of value of handle to sending control?
                                    Michael Mattias
                                    Tal Systems (retired)
                                    Port Washington WI USA
                                    [email protected]
                                    http://www.talsystems.com

                                    Comment


                                    • #19
                                      - LPARAM, WPARAM and LRESULT are used in the same way both in 32 and 64 bit. The only difference is that its size is 4 bytes in 32-bit and 8 bytes in 64-bit.

                                      - When setting the cbWndExtra member of the WNDCLASS structure, reserve 8 bytes instead of 4 for pointers when using a 64-bit compiler.

                                      - To access window or class private data that contains pointers use GetClassLongPtr, GetWIndowLongPtr, SetClassLongPtr, SetWindowLongPtr (if intended to use the same function name for both 32 and 64-bit you must write conditional aliases that call GetClassLong, GetWindowLong, SetClassLong, SetWindowLong when the compiler used is 32-bit)

                                      - UINT_PTR, INT_PTR, DWORD_PTR, LONG_PTR and ULONG_PTR are C++ defines or aliases that evaluate as 4 bytes when used with a 32-bit compiler and as 8 bytes when used with a 64-bit compiler. C++ uses a lot of defines to allow to compile an application that uses them to 32-bit or 64-bit without changing the code.

                                      - Handles are 4 bytes in 32-bit and 8 bytes in 64-bit. Again, C++ uses a lot of defines for them such HBITMAP, HBRUSH, HFONT, etc. All of them begin with an "H".

                                      - HRESULT is still defined as a LONG because although its name begins with an "H" is not an handle.

                                      - C++ int and long are 4 bytes both in 32 and 64 bit.

                                      - Some C++ constructs like size_t or time_t are 4 bytes in 32 bit and 8 bytes in 64 bit.

                                      - Alignment of structures that contain members such handles or pointers changes to 8 bytes (in 64-bit) instead of 4 bytes (32-bit). If the compiler does not do padding automatically, or it does it following different rules that C++ uses (e.g. PowerBasic, that uses the VB6 rules), you will have to adjust alignment using additional "filler" members.
                                      Forum: http://www.jose.it-berater.org/smfforum/index.php

                                      Comment


                                      • #20
                                        What has all this to do with "Discussions about the PB/WIN compiler, including its use with PB/Forms and PowerTree for Windows."

                                        Comment

                                        Working...
                                        X