****************** WinBatch+Comiler 2018B Beta release **********************

[td]

We have released WinBatch+Compiler 2018b beta.

Customers with a current license may download the beta version of the software from the download page.  Find beta software in the Alternatives
download list.

http://www.winbatch.com/download.html

If you do not have a current license and are interested in getting updated, please visit our software purchase page. You can easily order online.

https://commerce.winbatch.com

[td]

 WB 2018B (beta) May 02, 2018

  DLL 6.18brb Additions and changes included in WB 2018B
 
    Added support for two new "data type" values to IntControl 32.
       "LONG64"   - returns or sets a 64-bit integer value.
       "LONG_PTR" - returns or sets a 32-bit integer value in 32-bit WinBatch
                    and a 64-bit value in 64-bit WinBatch.
 
    Added support for the new "LONG_PTR" parameter type to the DllCall and DllCallcdec functions.
        "LONG_PTR" - accepts a 32-bit integer when called with 32-bit WinBatch and a 64-bit
                     integer when called with 64-bit WinBatch. (Values may be represented as
                     huge numbers.)
 
    Modified the BinaryTagInit function to accept an empty string in the start-tag (second)
    parameter. When the start-tag is an empty string, the function treats the beginning of
    the binary buffer as the start of the first tag pair. Any following pairs start just
    after the last found end-tag.
 
    New Function: 
       BinaryPeek8(i:handle, i:offset)
          BinaryPeek8 returns the 64-bit value as a huge number.
            "handle" - handle to binary buffer.
            "offset" - zero-based offset in the buffer of the first byte of the 64-bit value.

       BinaryPoke8(i:handle, i:offset, s/i:value)
          BinaryPoke8 adds an 8-byte value to a binary buffer starting at "offset".
             "handle" - handle to binary buffer.
             "offset" - zero-based offset in the buffer of the first byte of the 64-bit value.
             "value"  - 8-byte value to insert into the binary buffer at offset. Integer values
                        greater than or less than the maximum or minimum 4-byte signed integer
                        value must be represented by a huge number (digits enclosed in quotes.)

    64-bit WinBatch only: 
       Approximately doubled the maximum allowed number of array elements.
 
       Increased total string storage capacity by 50% to 375 MB.

       Increased the maximum size of a single binary buffer to 2GB. It is now also possible
       to have multiple binary buffers of up to 2GB allocated at the same time. The total
       memory available for all binary buffers is dependent on the maximum memory limit of the
       version of the 64-bit Windows operating system, and available physical and virtual memory
       of the system executing the script.
   
       Fixed problem that prevented 64-bit dialogs from loading the Browser and HTML COM servers
       into COMCONTROLs on Windows 10 version 1709 and newer versions of Windows.

       Modified the 64-bit Compiler to work around a defect in a security software product that
       could cause access violations in both compiled WinBatch script and the compiler.

    WinBatch Studio and WinBatch Compiler Lexical Analyzer changes:
       Added function parameter count checking for WIL Extenders, WinBatch Studio, and WinBatch
       functions.
     
       Added check for assignment to WIL Extender defined constants.  Note that assignment to
       a WIL Extender constant generates an error even if the extender is not loaded into the
       script being analyzed.

    WIL Dialog Editor changes:
       The Dialog Editor now loads and parses dialog templates without the assistance of the
       WIL interpreter DLL. Substitution is no longer performed on template string literals and
       the substitution syntax is preserved when embedded in the dialog's title, or a control's
       name and text attributes.
     
       It is possible to still load templates into the Dialog Editor using the WIL interpreter
       DLL by using one of the two new File menu items:
          Open with WIL                - Loads a template from a file with the assistance of the
                                         WIL interpreter DLL.
          Open from Clipboard with WIL - Loads a template form the clipboard with the assistance
                                         of the WIL interpreter DLL.

       When these two menu options are used, substitution is performed on the dialog templates
       so any substitution syntax will not be preserved when the loaded template is
       saved to the clipboard or a file.

       Note that the File menu's MRU menu items always use the WIL Dialog Editor's new built-in
       template loader/parser.

       Added the ability to scroll the Editor's dialog editing area.  This enables the creation
       of dialogs with dimensions that do not fit on the current system's display.

[kdmoyers]

Just a quick report on the Analyzer's interpretation of pointer references.
Most everything is recognized now, working great.  Yay!!

There's just one crazy looking, but legal and functional, analyzer thing left: It reports this as an error:

Code (winbatch) Select Expand

return *(arr[0])[row,z-1]
error 5062: Variable or function expected

This code works fine. The arr array's zeroth element is a pointer to a two dimensional array, the * dereferences it, and the row and column subscripts are applied.  I think perhaps the analyzer should not flag it as an error?

[kdmoyers]

Also, this might be me: when I compile using this beta compiler,
the resulting exe fails, saying it can't find WBDRB44I.DLL

Now this new version does come with wbdRB64i.dll, but not wbdRB44i.dll

so... what am I doing wrong? I feel like I've forgotten something...

[td]

The beta has both h wbdRB64i.dll and wbdRB44i.dll.  The former is the 64-bit WIL interpreter and the later is the latter is the 32-bit WIL interpreter.   You couldn't install WinBatch+Compiler if it didn't have wbdRB44i.dll.

You are likely getting the error because you compiled with the small model which means that exe does not have its own copy of the dll.  You usually provided the dll by placing a copy of the dll in the exe's start directory.

[td]

Just a quick report on the Analyzer's interpretation of pointer references.
Most everything is recognized now, working great.  Yay!!

There's just one crazy looking, but legal and functional, analyzer thing left: It reports this as an error:

Code (winbatch) Select Expand

return *(arr[0])[row,z-1]
error 5062: Variable or function expected

This code works fine. The arr array's zeroth element is a pointer to a two dimensional array, the * dereferences it, and the row and column subscripts are applied.  I think perhaps the analyzer should not flag it as an error?

It definitely should be able to handle that syntax. We will look into it.

[kdmoyers]

The beta has both h wbdRB64i.dll and wbdRB44i.dll.  The former is the 64-bit WIL interpreter and the later is the later is the 32-bit WIL interpreter.   You couldn't install WinBatch+Compiler if it didn't have wbdRB44i.dll.
You are likely getting the error because you compiled with the small model which means that exe does not have its own copy of the dll.  You usually provided the dll by placing a copy of the dll in the exe's start directory.

Thanks -- Got it - easily fixed.  I found the dll in the installation zip and hand copied it to C:\Program Files\WinBatch\System
Now everything works fine.

Funny that the setup script copied the 64i file but but not the 44i file.
Or maybe it did, but I somehow deleted it. I was looking around in there...

Thanks Tony, I'm all set now.

[td]

On 64-bit systems the main WinBatch installation directory is defaulted to "C:\Progam Files (x86)\WinBatch" and NOT "C:\Progam Files\WinBatch".   The directory "C:\Progam Files\WinBatch" is for the 64-bit versions of WinBatch dlls and exes that have 64-bit versions and very little else.  The WinBatch setup exe has never put 32-bit dlls into the 64-bit "Program Files" directory nor will it ever.

[kdmoyers]

Got it -- that's what I forgot.  Thanks Tony.