What i am especting from a bare compiler

[Peter Weis]

Hi Patrice,
To me it was so when I with Power Basic for Windwos when I started, after a long time with Power Basic again. As I know you, you'll get the fast in the grip. Must take care of you do not like in Power Basic to the whole area as in Power Basic. But a switch is always connected to work sustainably. It's annoying for you, that you at Power Basic is no alternative offered to you for that. Thank God I do not have to change!
Peter greetings

[Mike Stefanik]

No worries, it's like riding a bike. It might be a while, but it'll all come back to you. I think once you get used to the IDE (again) you'll really enjoy working with it. I think the Visual Studio IDE is really the best out there, but it can take some time to work out all of the features and how everything works vis a vis solutions, project options, multi-targeted builds, etc. There are some areas where the compilers could be improved, namely with Microsoft's selective support for the C99 standard and upcoming changes with C++0x. Although, to be fair, there's not really any mainstream compiler that supports everything, and C++0x is not a finalized standard. The one weak area with 2010 is the new and not-so-improved help system. I'd recommend downloading the Visual Studio Help Viewer addon, we have some info about it on our forums:

http://forums.catalyst.com/viewtopic.php?f=35&t=1336

In house, we still primarily use Visual Studio 2008 but we'll probably plan on migrating existing projects to 2010 sometime later this year. For now, we primarily use it to build .NET 4.0 assemblies.

[Eros Olmi]

Not to fire again 32/64 bits discussion but I saw this interesting article mentioned in PB forum by Bernhard Fomm:
http://windowsteamblog.com/windows/b/bloggingwindows/archive/2010/07/08/64-bit-momentum-surges-with-windows-7.aspx

[Mike Stefanik]

From everything I've read, that's been pretty much true since Windows 7 was released; of course, you have to keep in mind that all versions of Windows 7 still only accounts for about 14% of the overall market, and Vista is about 15%. The total number of 64-bit Windows systems out there are still <10% of total marketshare. The 32-bit version of Windows XP still accounts for >60% of all Windows systems.

With the release of Windows NT in 1993, the first truly 32-bit version of Windows, it took about a decade to transition away from 16-bit code. Windows XP x64 was released in 2005 (it was actually the Windows Server 2003 kernel, repackaged), so even if it follows along that same trajectory, we're looking at another 5 years. Of course, it's also the case that there's not as much of a compelling business interest in making the shift to 64-bit code. Remember that one of the things that finally got a lot of companies to dump their old 16-bit applications was the Y2K issue, where they were already in the mode of replacing hardware and upgrading software. That kind of impetus just doesn't exist today, so I suspect the adoption rate (by business) is going to be slower than the move from 16-bit to 32-bit.

[Theo Gottwald]

Mike, remember that even now, nearly all standalone PC's you buy have more memory (RAM) that a 32 bit OS can handle. Thats a different situation from the 16/32 switch time.

[Mike Stefanik]

Mike, remember that even now, nearly all standalone PC's you buy have more memory (RAM) that a 32 bit OS can handle. Thats a different situation from the 16/32 switch time.

You're thinking about home and gaming systems. If you look at business desktops (for example, the Dell Vostro and Optiplex lines), you'll see that most of those computers (the ones that sit on the desks of secretaries, accountants, etc.) come with 2GB of memory and downgrade rights to Windows XP. I've said this before -- don't confuse what you see with popular home computer lines from Dell, HP, etc. with the reality that the vast, vast majority of Windows desktops out there are business computers, running on trailing-edge hardware. In the business IT world, they are not early adopters, and they don't tend upgrade hardware or operating systems unless they absolutely have to in order to meet a specific need of their business.

I wrote about this on the PB forums, but when Microsoft reminded folks that Windows XP SP2 reaches end-of-life on July 13th, estimates (as of April this year) are that about 80% of businesses in the United States were still running XP SP2 as their primary operating system. Those folks are not going to be jumping on the 64-bit bandwagon any time soon. It's just not going to happen.

Edit: By the way, I don't want to give the impression that 64-bit development isn't useful; it's just that at this point it's nowhere near critical mass. When you start seeing widespread adoption of Windows 7 64-bit by businesses, then you'll see a real shift. At this point in the timeline, I'd say the move to 64-bit computing is about where 32-bit was when Windows 95 was released. My personal guestimate is that it's going to be another 5-8 years before we see a substantial move away from 32-bit code. Whenever you consider this, just keep in mind that the real drivers in the Windows desktop market are businesses, not home users.

[Patrice Terrier]

Mike,

I don't want to give the impression that 64-bit development isn't useful; it's just that at this point it's nowhere near critical mass

Programming embrass all the scope of human activity, a modern compiler must address the programmer's current need, that's all.

I am working today on the new features that would be part of my addons in one or two years, like a car manufacturer is working in 2010 on the model that would be sold in 2014.

...

[Edwin Knoppert]

>Programming embrass all the scope of human activity, a modern compiler must address the programmer's current need, that's all.
Hmm sounds kinda spoiled, i guess this is because many of the newer tools provide 64 bit support and even for free, yes we all are spoiled with that.

It's also odd that we 'approve' end-users to keep working with DOS bassed accountancy apps while we at the other end have a 'must-have' feeling regarding the compiler.
We support database-reading for old DOS apps, how can it be different?
(The lengths i went to to make it work..)

I understand your urge but would also want to stress that most of the programmers care much less for 64 bit.
Even worse, when i go to a 64 bit PowerBASIC executable.., how would i communicate with older ODBC drivers and such?
I am not so sure it will all work so well.
Imo you are in the 'latest-gadget' area, i mean the graphic support you offer.
It may well be only a few programmers are working in that area.

If i have a 32 bit app in need of calling once in a while 64 bit odbc driver i can still work it out, with graphics you won't.

I suspect that there will be a big gap between 32 bit apps and 64 bit apps for many many years, i mean for only targeting to a specific area.

[Theo Gottwald]

Windows 7: 46% of all sold Computers use Window 7/64

WinFuture - Message

Microsoft führt die zunehmende Verbreitung der 64-Bit-Ausgaben von Windows 7 unter anderem auf gesunkene RAM-Preise zurück, wodurch die PC-Hersteller ihre Systeme mit mehr Arbeitsspeicher ausstatten können. Außerdem unterstützen die meisten heute verfügbaren Prozessoren 64-Bit-Betriebssysteme und die Zahl der kompatiblen Geräte steigt stetig.

Die PC-Hersteller setzen mittlerweile voll auf 64-Bit. So haben einige Anbieter ihre gesamte Produktpalette umgestellt, weshalb laut Marktforschern 77 Prozent der in den USA verkauften neuen Computer bereits mit einer 64-Bit-Version von Windows 7 daher kommen. Auch im Business-Bereich wird auf Windows 7 64-Bit umgestellt, rechnen Marktforscher doch damit, dass schon 2014 75 Prozent der amerikanischen Firmen eine solche Version einsetzen werden.

Yesterday i have read an article in a computer magazine, which has tested the new "Delphi" Compiler.
They said that after all this company should quickly deliver a 64-bit version or it may be overrun by the competitors, soon.

[Edwin Knoppert]

Maybe i am overreacting as well, just read about w7 64 bits being sold so much, it may well be that several 32 bit drivers work fine in such an os.
That i don't know.
Hopefully since i would like to make the jump at some point, the prospect of having an improved memory management is attempting
I guess i'll make the jump with w8 or so.

[Patrice Terrier]

I couldn't imagine myself developping third party addons, without checking them on the latest available Windows version.

This is how i realised that i couldn't use anymore, something as simple as, the EnumChildWindow, when the target window is a 64-bit application, for example with the "#32769" desktop.

Added:
To ease the translation from 32-bit to 64-bit, WinDev uses this syntax:
gnParent is system int = Handle("MyWindow")

this means gnParent will be either 32 or 64-bit whatever the OS being used, simple isn't it?
(Note: WinDev itself is C++, and it works a little like BCX or managed C# if you prefer the OOP syntax)

....

[Mike Stefanik]

Yesterday i have read an article in a computer magazine, which has tested the new "Delphi" Compiler.
They said that after all this company should quickly deliver a 64-bit version or it may be overrun by the competitors, soon.

In truth, they've already been "overrun" by Microsoft quite a while ago. Embarcadero/CodeGear is several steps behind in both their native and .NET compilers. From what I've read, they've been focusing on cross-platform support, and won't have a 64-bit compiler until at least 2012.

Edwin, just so you know, you can't use 32-bit drivers in 64-bit versions of Windows. Drivers need to be 64-bit, and they need to be digitally signed using KMCS (kernel mode code signing). For logo compliance, the driver also needs to be submitted to Microsoft for WHQL certification.

[Mike Stefanik]

This is how i realised that i couldn't use anymore, something as simple as, the EnumChildWindow, when the target window is a 64-bit application, for example with the "#32769" desktop.

I'm not sure why you think this, is it because of the size of the window handle? A 32-bit process can enumerate windows that belong to a 64-bit process without a problem, and can even send those windows messages. Although the handles on an x64 system are 64-bit, only the lower 32 bits are significant; the upper 32 bits are always zero. It's perfectly safe to cast a 64-bit handle to a 32-bit integer and back again (as long as it's an actual handle, not a pointer).

32-bit and 64-bit processes can send Windows messages to each other, use RPC and other IPC mechanisms, and with some limitations, can share memory. The only sticking point is if pointers are being used; for example, Windows messages that expect pointers to be passed in the LPARAM argument won't work because they'll be truncated.

http://msdn.microsoft.com/en-us/library/ee872017.aspx

[Patrice Terrier]

Mike,

I am speaking of pointer of course.

I am doing interprocess communication with the undelaying OS using:

VirtualAllocEx
OpenProcess
WriteProcessMemory
ReadProcessMemory

Example of problematic code:

Code Select Expand

SUB CreateShortCut(BYVAl hWnd AS LONG)

    LOCAL nFound, nCount, nLeft, nRight, nHeight, hBitmap AS LONG
    LOCAL K, nItemCount, nCenter AS LONG, sLink, sUseThumb AS STRING
    LOCAL rw AS RECT

    gnXoffset = 0

    IF UBOUND(gS) > 0 THEN '// Clear existing bitmap
       FOR K = 1 TO UBOUND(gS)
           IF gS(K).hBitmap THEN DeleteObject(gS(K).hBitmap): gS(K).hBitmap = 0
       NEXT
    END IF
    nCenter = (gS(0).w - 48) \ 2

    ghProgMan  = FindWindow("Progman", "Program Manager")
    ghListView = FindWindowEx(ghProgMan, 0, "SHELLDLL_DefView", "")
    ghListView = FindWindowEx(ghListView, 0, "SysListView32", "FolderView")
    nItemCount = SendMessage(ghListView, %LVM_GETITEMCOUNT, 0, 0)
    IF nItemCount THEN
       LOCAL dwProcessId, hProcess, dwSize, lpData AS DWORD
       CALL GetWindowThreadProcessId(ghListView, dwProcessId)
       hProcess = OpenProcess(%PROCESS_VM_OPERATION OR %PROCESS_VM_READ OR %PROCESS_VM_WRITE, %FALSE, dwProcessId)
       IF hProcess THEN
          '// Compute the size of our reserved memory buffer
          dwSize = SIZEOF(POINTAPI) + SIZEOF(LVITEM) + %MAX_PATH * 2

          lpData = VirtualAllocEx(hProcess, BYVAL %NULL, dwSize, %MEM_COMMIT, %PAGE_READWRITE)
          IF lpData THEN

             LOCAL pWsh AS IWshShell
             pWsh = NEWCOM "WScript.Shell"
             LOCAL pLnk AS IWshShortcut
'            Shortcut description:       ACODE$(pLnk.Description)
'            Shortcut working directory: ACODE$(pLnk.WorkingDirectory)
'            Shortcut arguments:         ACODE$(pLnk.Arguments)
'            Shortcut hot key:           ACODE$(pLnk.HotKey)
'            Shortcut icon location:     ACODE$(pLnk.IconLocation)
'            Shortcut target path:       ACODE$(pLnk.TargetPath)
'            Shortcut window style:      FORMAT$(pLnk.WindowStyle)

             LOCAL sDeskTopPub, sDeskTopAdm, sTempPath AS STRING
             'sDeskTopTray$ = zsFolderGet(&H000A) '// %CSIDL_BITBUCKET ' <desktop>\Recycle Bin
'            %CSIDL_STARTMENU            = &H000b  ' <user name>\Start Menu
'            %CSIDL_DESKTOPDIRECTORY     = &H0010  ' <user name>\Desktop
             sDeskTopAdm = zsFolderGet(%CSIDL_DESKTOP)
             sDeskTopPub = zsFolderGet(%CSIDL_COMMON_DESKTOPDIRECTORY)
             sTempPath = zGetTempPath()
             '// Setup pointers
             LOCAL lpPosition, lpItem, lpText, nIconVisibleAtOnce AS LONG
             lpPosition = lpData
             lpItem = lpData + SIZEOF(POINTAPI)
             lpText = lpData + SIZEOF(POINTAPI) + SIZEOF(LVITEM)

             LOCAL lvi AS LVITEM
             LOCAL szTxt AS ASCIIZ * 128, szLnk AS ASCIIZ * (%MAX_PATH * 2)  ' Allow room for unicode
             LOCAL DoLnk AS LONG
             CALL GetWindowRect(hWnd, rw)
             nHeight = (rw.nBottom - rw.nTop) - 75
             FOR K = 0 TO nItemCount - 1
                 '// Init LVITEM structure and copy it to our reserved memory buffer
                 lvi.mask       = %LVIF_TEXT
                 lvi.iItem      = K
                 lvi.iSubItem   = 0
                 lvi.pszText    = lpText
                 lvi.cchTextMax = %MAX_PATH * 2
                 CALL WriteProcessMemory(hProcess, lpItem, lvi, sizeof(LVITEM), 0)
                 '// Get text label and x,y location
                 CALL SendMessage(ghListView, %LVM_GETITEMTEXT, K, lpItem)
                 CALL SendMessage(ghListView, %LVM_GETITEMPOSITION, K, lpPosition)
                 '// Copy from process memory to local variables
                 szTxt = ""
                 CALL ReadProcessMemory(hProcess, lpText, szTxt, SIZEOF(szTxt), 0)
                 LOCAL p AS POINTAPI
                 CALL ReadProcessMemory(hProcess, lpPosition, p, SIZEOF(POINTAPI), 0)
                 IF LEN(szTxt) THEN szLnk = szTxt + ".lnk"

                 IF ISFILE(sDeskTopAdm + szLnk) THEN
                    sLink = sDeskTopAdm + szLnk
                 ELSEIF ISFILE(sDeskTopPub + szLnk) THEN
                    sLink = sDeskTopPub + szLnk
                 ELSE
                    sLink = ""
                 END IF

                 sTarget$ = ""
                 IF LEN(sLink) THEN
                    DoLnk = -1
                    pLnk = pWsh.CreateShortcut(UCODE$(sLink))
                    'sTarget$ = PARSE$(ACODE$(pLnk.IconLocation), 1)
                    'IF LEN(sTarget$) = 0 THEN sTarget$ = ACODE$(pLnk.TargetPath)
                    sTarget$ = RTRIM$(ACODE$(pLnk.TargetPath))
                    IF LEN(sTarget$) = 0 THEN sTarget$ = ResolveLnk((sLink))
                    '// Hide the own OTB shorcut
                    IF LCASE$(sTarget$) = LCASE$(EXE.FULL$) THEN sTarget$ = ""
                 ELSE
                    DoLnk = 0
                    sTarget$ = ResolveShortcutName(szTxt)
                 END IF
                 IF LEN(sTarget$) THEN
                    INCR nFound
                    IF CreateBarIcon((sTarget$), nFound) THEN
                       INCR nCount
                       REDIM PRESERVE gS(%LBOUND TO nCount)
                       gS(nCount).y = nHeight: gs(nCount).scale = %SCALE_DEFAULT: gS(nCount).opacity = 255
                       sUseThumb = sTempPath + "OfTheBay" + STR$(nFound) + ".png"
                       gS(nCount).hBitmap = CreateDockIcon((sUseThumb), gS(nCount).w, gS(nCount).h)
                       CALL zKillFile((sUseThumb))
                       IF DoLnk THEN gS(nCount).ShellTo = LCASE$(ACODE$(pLnk.TargetPath))
                       IF DoLnk THEN gS(nCount).WorkDir = ACODE$(pLnk.WorkingDirectory)
                       gS(nCount).UseLabel = szTxt
                       IF DoLnk THEN gS(nCount).ShowCmd = pLnk.WindowStyle

                       gS(nCount).focusXY = MAKLNG(p.X + 10, p.Y + 10)
                    END IF

                 END IF
             NEXT

             '// Freeup memory
             CALL VirtualFreeEx(hProcess, lpData, 0, %MEM_RELEASE)


'            ****************************************************
             CALL ReadCustomShortcuts(nFound, nCount, nHeight, p)
'            ****************************************************

             '// Setup icon x location
             nIconVisibleAtOnce = (gS(0).w - 88) \ 48
             FOR K = 1 TO nCount

                IF nCount < nIconVisibleAtOnce + 1 THEN ' Center it on the Bar
                   IF K MOD 2 = 0 THEN
                      INCR nRight
                      gS(K).x = nCenter + (48 * nRight)
                   ELSE
                      gS(K).x = nCenter - (48 * nLeft)
                      INCR nLeft
                   END IF
                ELSE
                   gS(K).x = 44 + (48 * (K - 1))
                END IF
             NEXT

          END IF

          '// Close process
          CALL CloseHandle(hProcess)

       END IF
    END IF
END SUB


[Edwin Knoppert]

Geeh imo you are dealing with code you'll never keep up with.
'Progman'.., man, that's about 200 years old..
Then the assumption desktop's are kept being treated the same for long time by Windows?
If there isn't a solid api for it, better not pursuit it?