Inno Setup 6 cannot use DLL function with string parameters, while it works in Inno Setup 5 - dll

We are currently using Inno Setup version 5.5.3 to build an installer. I am planning to upgrade this version to 6.1.2.
We use Inno Setup for installation of our product. We ship a license code along with installer, and user enters the license in a field during installation.
This license is validated using a custom DLL and a non negative result is returned by DLL for valid license.
This process works fine in 5.5.3 and 5.6.1, but fails in version 6 (tested with 6.0.5 and 6.1.2).
Unfortunately there are no logs generated that point the exact issue.
This custom DLL is 32-bit and is built using C++ over 10 years ago. There are no plans to redo this part. Is there any way to use the same DLL and fix the problem? Thank you.
[Files]
Source: mydll.dll; Flags: dontcopy
// This function calls the external mydll which parses licenseCode and
// returns an integer
function getFlags( secret, licenseCode : String) : Integer;
external 'getFlags#files:mydll.dll cdecl';
function checkLicense(license : String) : Boolean;
var
secret : String;
begin
Result := False; // default is Incorrect license
license := Trim(license);
secret := <secret>
// This line calls the above getFlags function and expects to get an integer
license_flags := getFlags( secret, license);
if license_flags = -1 then begin
if not suppressMsgBox then begin
MsgBoxLog( ‘Incorrect License’)
end;
Exit;
end;
Result := True;
end;
// This is the c++ function
PS_EXPORT(int) getFlags( const char * secret, const char * license ) {
// This function is returning -1 for Inno Setup 6
// but works fine for Inno Setup 5
if (strlen(license) == 0)
return -1;
...
}

This is not a 5.x vs 6.x issue, nor a bitness issue. This is an Ansi vs. Unicode issue.
In 5.x, there were two versions of Inno Setup, Ansi version and Unicode version. You were probably using the Ansi version and your code is designed for it. In 6.x, there's only the Unicode version. Your code does not work in the Unicode version. By upgrading to 6.x, you inadvertently also upgraded from Ansi to Unicode.
A quick and dirty solution is to change the declaration of the getFlags function to correctly declare the parameters to be Ansi strings (AnsiString type):
function getFlags( secret, licenseCode : AnsiString) : Integer;
external 'getFlags#files:mydll.dll cdecl';
The correct solution would be to reimplement your DLL to use Unicode strings (wchar_t pointers):
PS_EXPORT(int) getFlags( const wchar_t * secret, const wchar_t * license )
This is a similar question: Inno Setup Calling DLL with string as parameter.
See also Upgrading from Ansi to Unicode version of Inno Setup (any disadvantages).

Related

go-redis does it have support for registering / executing lua functions

From its version 7.x onwards, Redis has introduced functions, as an alternative to script execution, as documented here.
I am looking for an example, or documentation on how to use redis functions using go-redis package. Not sure, if go-redis supports this feature yet.
Thanks for anyone letting me know about this.
I searched a bit more in the official documentation of go-redis, which has a way of executing unsupported commands using the Do, as mentioned here.
// Defind the function code..
fcode := `#!lua name=mylib
redis.register_function('myfunc',
function (keys, args)
return args[1]
end)`
// Load or replace the function
val, err := rdb.Do(ctx, "function", "load", "replace", "<function code text>").Result()
// later in the code... call the function
va, err := rdb.Do(ctx, "fcall", "myfunc", 0, "hello").Result()

aurelia-cli error when using buffer.js - global undefined

Created a new project using the aurelia-cli - SystemJS bundler option.
installed htmlparser2 module from npm which has buffer.js as a dependency.
getting the following error when attempting to import htmlparser2:
bluebird.core.js:3434 Error: global is not defined
Evaluating http://localhost:9000/buffer/index
upon inspecting vendor-bundle -> this is the line that creates the error:
Buffer.TYPED_ARRAY_SUPPORT = global.TYPED_ARRAY_SUPPORT !== undefined
? global.TYPED_ARRAY_SUPPORT
: typedArraySupport()
found a similar issue with angualar-cli where the solution was to manually turn on node global
Node global is turned off. It works fine if I manually turn it on again.
The question is how to do this using the aurelia-cli? Any suggestions?
larger code snippet from vendor-bundle
define('buffer/index',['require','exports','module','base64-js','ieee754','isarray'],function (require, exports, module) {/*!
* The buffer module from node.js, for the browser.
*
* #author Feross Aboukhadijeh <feross#feross.org> <http://feross.org>
* #license MIT
*/
/* eslint-disable no-proto */
'use strict'
var base64 = require('base64-js')
var ieee754 = require('ieee754')
var isArray = require('isarray')
exports.Buffer = Buffer
exports.SlowBuffer = SlowBuffer
exports.INSPECT_MAX_BYTES = 50
/**
* If `Buffer.TYPED_ARRAY_SUPPORT`:
* === true Use Uint8Array implementation (fastest)
* === false Use Object implementation (most compatible, even IE6)
*
* Browsers that support typed arrays are IE 10+, Firefox 4+, Chrome 7+, Safari 5.1+,
* Opera 11.6+, iOS 4.2+.
*
* Due to various browser bugs, sometimes the Object implementation will be used even
* when the browser supports typed arrays.
*
* Note:
*
* - Firefox 4-29 lacks support for adding new properties to `Uint8Array` instances,
* See: https://bugzilla.mozilla.org/show_bug.cgi?id=695438.
*
* - Chrome 9-10 is missing the `TypedArray.prototype.subarray` function.
*
* - IE10 has a broken `TypedArray.prototype.subarray` function which returns arrays of
* incorrect length in some situations.
* We detect these buggy browsers and set `Buffer.TYPED_ARRAY_SUPPORT` to `false` so they
* get the Object implementation, which is slower but behaves correctly.
*/
Buffer.TYPED_ARRAY_SUPPORT = global.TYPED_ARRAY_SUPPORT !== undefined
? global.TYPED_ARRAY_SUPPORT
: typedArraySupport()
I believe you are using cli built-in bundler (I wrote it), not webpack.
Yes, nodejs global var global is currently not supported. Also nodejs global vars process and Buffer have similar issues.
The cli doc has a patch to support process and Buffer.
import process from 'process';
window.process = process;
import {Buffer} from 'buffer';
window.Buffer = Buffer;
You can try to add one more patch for global.
window.global = window;
Ok why cli has the issue
cli's tracing algorithm uses rjs (requirejs optimizer) parser, it's bit old, does not detect global vars (technically it does not do variable scope analysis).
I have another WIP bundler called dumber which solved the limitation with a new parser which detects global vars. It automatically patch nodejs global vars at module level based on need.
In long term, we will drop the code for cli built-in bundler, then wrap dumber and make it backward compatible.

Retrieve version number from another exe [duplicate]

Salvete! I am writing a vb.net program to update the readme files for my applications. I want to extract the version number from other compiled applications. I want to read the version number from the executable, not from its uncompiled resources.
How can I do this in vb.net without using an external tool like reshacker?
(I found this link, but it is for another language.)
You can use a function like this to do it:
Private Function GetFileVersionInfo(ByVal filename As String) As Version
Return Version.Parse(FileVersionInfo.GetVersionInfo(filename).FileVersion)
End Function
Usage:
Debug.WriteLine(GetFileVersionInfo("C:\foo\bar\myapp.exe").ToString)
Output:
4.2.9.281

Webstorm generator function not accepted

I'm trying to use iojs with koa, what works well. But Webstorm doesn't accept the generator functions as valid.
/** gets marked as syntactically invalid code */
app.use(function *() {
this.body = 'Hello World';
});
My actual version is Webstorm 9.
Is there maybe a workaround? I couldn't find a matching option for it.
Go to the Preferences > Languages & Frameworks > JavaScript and chose ECMAScript 6 for JavaScript language version.

DWScript Write/Read a simple text file

I would like to write/read a simple text file using dwscript.
My code is here below... but I am non able to get it run, please someone might help...:
(I am using the Simple.exe in the Demos folder of DWS installation)
// uses Classes;
{$INCLUDE_ONCE 'c:/.../System.Classes.pas'}
var
s: TFileStream;
o: string; // out
i: integer;
f: word; // flag
f := fmOpenReadWrite;
if not FileExists('C:\Temp\Junkfile.txt') then
f := f or fmCreate;
s := TFileStream.Create('C:\Temp\Junkfile.txt', f);
try
s.Position := s.Size; // will be 0 if file created, end of text if not
for i := 1 to 10 do begin
o := Format('This is test line %d'#13#10, [i]);
s.Write(o[1], Length(o) * SizeOf(Char));
end;
finally
s.Free;
end;
By default the script engine keeps everything sand-boxed and nothing that gives access outside the sandbox is exposed. So if you want to give access to arbitrary files to script you need to expose functions & classes to achieve it (through TdwsUnit f.i.).
Also it won't compile the Delphi classes unit, DWScript is not meant to be an alternative to the Delphi compiler, but to offer scripting support, ie. allow end users to run code in a way over which you have full control over what they can do, and that can't crash or corrupt the host application (that last point being the key differentiation with the other notable Pascal scripting engines).
You can use dwsFileFunctions to get basic file I/O support, in which case an equivalent to the file creation portion of your code would be something like
var f := FileCreate('C:\Temp\Junkfile.txt');
for var i := 1 to 10 do
FileWrite(f, Format('This is test line %d'#13#10, [i]));
FileClose(f);