Bug#1068789: nsis: build fails if version number has buildX or ubuntuX suffix

[Thomas Gaugler]

Thanks for making me aware of the issue.

I’d like to fix this issue for other Debian derivatives such as Linux Mint as 
well.

Would the following change work for you?

VER_REVISION=$(shell echo $(firstword $(subst +, ,$(word 
3,$(VERSION_DECOMPOSED | sed 's/[^0-9]//g')

Are there any other suffixes beside build and lowercase $(dpkg-vendor --query 
Vendor) followed by the revision number?

Bug#1050588: bookworm-pu: package nsis/3.08-3+deb12u1

[Thomas Gaugler]

Control: tags -1 -moreinfo
Control: owner -1 Thomas Gaugler 

Hi Adam,

I am the maintainer of Nullsoft Scriptable Install System (NSIS) and 
propose the changes committed into the debian/bookworm branch on the 
27th January 2024 to be released as updated nsis 3.08-3+deb12u1 packages 
(<https://salsa.debian.org/debian/nsis/-/commits/debian/bookworm>).


The changes fix the security vulnerability CVE-2023-37378 
(<https://security-tracker.debian.org/tracker/CVE-2023-37378>), bogus 
relocation section in the installer stubs 
(<https://bugs.debian.org/1050288>) and a failed to build from source 
(FTBFS) bug occurring in the arm64 reproducibility build 
(<https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/nsis.html>).


In the following I describe each commit in more detail.

2b331c4f Cherry-pick upstream commits to fix CVE-2023-37378
This commit consists of essentially the same patches as included in the 
nsis 3.04-1+deb9u1 diff uploaded by the LTS Security team. Only the 
Debian patch header fields differ slightly.

(<http://security.debian.org/debian-security/pool/updates/main/n/nsis/nsis_3.04-1+deb9u1.debian.tar.xz>),
(<https://lists.debian.org/debian-lts-announce/2023/07/msg5.html>),
(<https://tracker.debian.org/news/1442453/accepted-nsis-304-1deb9u1-source-into-oldoldstable/>)

105629f0 Use common options for nsis-doc installation
In Debian Trixie additional compile flags for hardening the security 
have been introduced. These flags were wrongly applied for installing 
build artifacts of the documentation targets (install-examples, 
install-doc and install-docs) and caused the arm64 reproducibility build 
to fail. The arm64 reproducibility worked again after changing to the 
common set of flags for the documentation targets build. 
(<https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/nsis.html>)


2d1e47e8 Exclude Debian revison suffix from VER_REVISION
The nsis 3.04-1+deb9u1 diff did "Hardcode VER_REVISION to ignore deb9u1 
suffix". This change takes a generic approach by utilizing the string 
functions (firstword, word) of make to exclude the Debian revision 
suffix from VER_REVISION.


1ec70a5e Backport upstream commit to disable stub relocations
The original fix was not effective 
(<https://salsa.debian.org/debian/nsis/-/commit/f1c043cc110797e9f06718e7bc13b7163b78c550>). 
This regression was pointed out in the Debian bug report #1050288 
(<https://bugs.debian.org/1050288>) and the origin of this proposed 
update request. These changes are the back port of the upstream commit 
to disable stub relocations in newer GNU C(++) compiler versions.


f5795972 CVE-2023-37378, nsis-doc, VER_REVISION, disable relocs
This commit documents the above described changes.

---

Once we have your agreement, my uploading sponsor (OdyX) will proceed 
with the upload.


Best regards,
Thomas

Bug#1050288: nsis 3.08-3 (bookworm) generates bogus relocation information (regression)

[Thomas Gaugler]

Thank you for your detailed bug report.

I built the nsis_3.09-1 and nsis-common_3.09-1 packages on Debian 
Bookworm, installed the resulting packages and can confirm with the two 
Nullsoft Installer (.nsi) scripts provided by you that the resulting 
installer executables no longer show the "(.reloc) is too large" error 
with objdump.


Therefore I would appreciate if you create a "bookworm proposed updates 
request" by issuing the "reportbug release.debian.org" command on a 
Debian system.


Please mention in "reportbug" this bug report, provide your observations 
and results of your tests and also refer to the fixed security 
vulnerability (Bug#1040880: nsis: CVE-2023-37378) in nsis_3.09-1.

Bug#1010488: win32-loader: please annotate the wine Build-Depends with

[Thomas Gaugler]

Fixed with the following commit:

Bug#962161: Add dependency to #972268

[Thomas Gaugler]

Control: block -1 972268

Bug#972268: ipxe-signed - PXE boot firmware EFI signed binary

[Thomas Gaugler]

Source: ipxe
Severity: wishlist
X-Debbugs-Cc: o...@debian.org

Dear Maintainer,

I would like to enable PXE booting within the win32-loader package under
an UEFI Secure Boot regime.

The original request (https://bugs.debian.org/962161) did not include
the secure boot requirement. However a signed ipxe efi binary would
simplify the matter for the users.

I guess an approach similar to the fwupdate-amd64-signed could be taken
to provide a signed PXE boot firmware EFI binary.

Thanks in advance!

Bug#947572: FTBFS with scons 3.1.2-1

[Thomas Gaugler]

Thank you for your bug report.

The version 3.05 of NSIS should result in a successful build via scons 
requiring Python 3 compatible syntax. In particular the included commit 
#7124 "Port SCons scripts to py3k (xantares/py3k PR)" [1] addresses that.


I am going to work on the upgrade of the NSIS Debian package to version 
3.05.


[1] https://sourceforge.net/p/nsis/code/7124/

Bug#942396: nsis: increase NSIS_MAX_STRLEN to 8192

[Thomas Gaugler]

I just imagined to have one additional package. Let's call it 
nsis-special for the sake of simplicity.


nsis-special would have the following content:
/usr/share/nsis/Special/8kStrings/bzip2_solid-x86-ansi
/usr/share/nsis/Special/8kStrings/bzip2_solid-x86-unicode
/usr/share/nsis/Special/8kStrings/bzip2-x86-ansi
/usr/share/nsis/Special/8kStrings/bzip2-x86-unicode
/usr/share/nsis/Special/8kStrings/lzma_solid-x86-ansi
/usr/share/nsis/Special/8kStrings/lzma_solid-x86-unicode
/usr/share/nsis/Special/8kStrings/lzma-x86-ansi
/usr/share/nsis/Special/8kStrings/lzma-x86-unicode
/usr/share/nsis/Special/8kStrings/uninst
/usr/share/nsis/Special/8kStrings/zlib_solid-x86-ansi
/usr/share/nsis/Special/8kStrings/zlib_solid-x86-unicode
/usr/share/nsis/Special/8kStrings/zlib-x86-ansi
/usr/share/nsis/Special/8kStrings/zlib-x86-unicode
/usr/share/nsis/Special/Logging/bzip2_solid-x86-ansi
/usr/share/nsis/Special/Logging/bzip2_solid-x86-unicode
/usr/share/nsis/Special/Logging/bzip2-x86-ansi
/usr/share/nsis/Special/Logging/bzip2-x86-unicode
/usr/share/nsis/Special/Logging/lzma_solid-x86-ansi
/usr/share/nsis/Special/Logging/lzma_solid-x86-unicode
/usr/share/nsis/Special/Logging/lzma-x86-ansi
/usr/share/nsis/Special/Logging/lzma-x86-unicode
/usr/share/nsis/Special/Logging/uninst
/usr/share/nsis/Special/Logging/zlib_solid-x86-ansi
/usr/share/nsis/Special/Logging/zlib_solid-x86-unicode
/usr/share/nsis/Special/Logging/zlib-x86-ansi
/usr/share/nsis/Special/Logging/zlib-x86-unicode
plus some documentation what it is and how to use it.

This package provides the stubs of the special builds (namely "Advanced 
logging" and "Large strings") as described on the NSIS Special Build web 
page (https://nsis.sourceforge.io/Special_Builds).


I would prefer to be consistent with upstream. Therefore I am hesitant 
adding more stubs (e. g. combination advanced logging and large strings) 
to the nsis-special package.


More details how I intend to proceed are available at:
https://sourceforge.net/p/nsis/feature-requests/552/

Please provide your feedback. I might have overlooked some things that 
are important to you.

Bug#942396: nsis: increase NSIS_MAX_STRLEN to 8192

[Thomas Gaugler]

The discussion within bug report #432713 
(https://bugs.debian.org/432713) is relevant here as well.


Nevertheless I think it might be worthwhile providing the stubs of the 
special builds of "advanced logging" and "large strings" via an optional 
Debian package.


Unfortunately it is not sufficient to only provide the stubs of the 
special builds. The makensis executable is not generic enough to cope 
with the default and special builds. So for each build the stubs and the 
respective makensis compiler is required.


My preference would be to have just one generic makensis compiler 
dynamically supporting the default and special builds.

Bug#922797: Wish for inclusion of ntfs, ntfscomp and http modules

[Thomas Gaugler]

Package: grub-efi-amd64-signed
Version: 1+2.02+dfsg1+11
Severity: wishlist

win32-loader installs the Linux kernel and initial ramdisk file in the
win32-loader folder of the system drive.

The inclusion of the ntfs and ntfscomp modules into the
grub-efi-amd64-signed package would allow grub to access the
win32-loader folder residing on a NTFS partition even under a secure
boot regime.

See also:
https://bugs.debian.org/918863
https://salsa.debian.org/snippets/270

If http would be available in the grub-efi-amd64-signed package then
something like the following might bring the Debian Installer to life:

net_bootp efinet0
set root=(http,deb.debian.org)
linux

/debian/dists/testing/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux
 priority=low vga=788 ---
initrd

/debian/dists/testing/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz
boot

This approach uses the public http server of Debian and running your own
server for example in the case of using the tftp network protocol could
be eliminated.

-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Thomas Gaugler]

See  for a proof of concept.

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Thomas Gaugler]

The BOOTCFG_IsUEFI function in include/bootcfg.nsh could be used to 
detect the firmware type (legacy BIOS versus UEFI).


I thought to use the momentum around secure boot within Debian [2] for 
supporting it within win32-loader as well.


The basic idea is to replicate the following commands in win32-loader:
$ # Copy /usr/lib/shim/shimx64.efi.signed from shim-signed package to
$ # /boot/efi/EFI/debian/shimx64.efi
$ sudo efibootmgr --create --label 'Debian GNU/Linux - Continue with 
install process' --loader '\EFI\debian\shimx64.efi'

...
Boot0009* Debian GNU/Linux - Continue with install process ...
$ sudo efibootmgr --bootnext 0009

I have not yet investigated how ipxe.efi from the ipxe package could be 
chainloaded from either shim or grub2.


[2] 



 Original Message 

Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :

If such a system is detected, maybe a warning could be added?


Sure. I suggest this would be done very early, but have no clue how to detect
such a system. This would also make sense in time for buster. Could you work
on a patch? Thomas; an idea?


A short search led to function kernel32!GetFirmwareType [1].
That is said to be supported since windows 8.

This function is already used in include/bootcfg.nsh, but
can not see any user, maybe just a preparation for future use ...

Kind regards,
Bernhard

[1] 
https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-getfirmwaretype

Bug#919023: Simplification of BOOTCFG_CreateGUID function

[Thomas Gaugler]

Package: win32-loader
Version: 0.9.3
Severity: normal
Tags: patch

The conversion of an UUID value into a string can be achieved by just 
using the g (GUID) type of the System plug-in. As a consequence the 
Win32 API calls could be eliminated.


-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

win32-loader depends on no packages.

win32-loader recommends no packages.

Versions of packages win32-loader suggests:
pn  wine  
>From e735da16c5059c680d279a00de8cdf3c0e1bf53e Mon Sep 17 00:00:00 2001
From: Thomas Gaugler 
Date: Fri, 11 Jan 2019 22:04:52 +0100
Subject: [PATCH] Simplification of BOOTCFG_CreateGUID function

The conversion of an UUID value into a string can be achieved by just using the g (GUID) type of the System plug-in. As a consequence the Win32 API calls could be eliminated.
---
 include/bootcfg.nsh | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/include/bootcfg.nsh b/include/bootcfg.nsh
index 59ca3f4..3b087e4 100644
--- a/include/bootcfg.nsh
+++ b/include/bootcfg.nsh
@@ -1868,7 +1868,6 @@ FunctionEnd
   Push $0
   Push $1
   Push $2
-  Push $3
 
   ; Initialize return value
   StrCpy $0 ""
@@ -1876,24 +1875,11 @@ FunctionEnd
   ${If} $2 != 0
 System::Call "rpcrt4::UuidCreate(p r2) i.r1"
 ${If} $1 == 0
-  ; Create reference pointer
-  System::Call "*() p.r3"
-  ${If} $3 != 0
-System::Call "rpcrt4::UuidToString(p r2, pr3r3) i.r1"
-${If} $1 == 0
-  ; Extract string from reference pointer
-  System::Call "*$3(p .r0)"
-  System::Call "*$0(${NSIS_MAX_STRLEN} .r0)"
-  StrCpy $0 "{$0}"
-  System::Call "rpcrt4::RpcStringFree(pr3)"
-${EndIf}
-System::Free $3
-  ${EndIf}
+  System::Call "*$2(g .r0)"
 ${EndIf}
 System::Free $2
   ${EndIf}
 
-  Pop $3
   Pop $2
   Pop $1
   Exch $0
-- 
2.20.1

Bug#918376: nsis 3.03-2: FTBFS, alignment problem

[Thomas Gaugler]

Thanks for your detailed bug report.

I tried to reproduce the bug via the Disco Dingo Ubuntu/arm64 cloud 
image running inside the QEMU emulator [1]. I did not succeed in 
triggering the bug with this setup.


I concluded from your debug output that the icon group boundary is not 
aligned to the nearest multiple of a double word.


The size of the icon group is calculated as the following:
   size_t group_size = sizeof(IconGroupHeader) // header
 + order.size() * SIZEOF_RSRC_ICON_GROUP_ENTRY; // entries

sizeof(IconGroupHeader) = 6
SIZEOF_RSRC_ICON_GROUP_ENTRY = 14

group_size is a multiple of a double word for uneven numbers of 
order.size() but not if order.size() is an even number.


For illustration group_size for the order.size() values of 1 and 2:
group_size = 6 + 1 * 14 = 20 (double word aligned)
group_size = 6 + 2 * 14 = 34 (not double word aligned)

Therefore I expect something like the attached patch 
(fix-icongroup-alignment.patch) would be necessary. I need to verify 
with the
Microsoft Portable Executable and Common Object File Format 
Specification [2] and upstream.


[1] https://wiki.ubuntu.com/ARM64/QEMU
[2] http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
Align icon group boundary to the nearest multiple of a double word.
--- a/Source/icon.cpp
+++ b/Source/icon.cpp
@@ -341,8 +341,12 @@
   // calculate size
   size_t group_size = sizeof(IconGroupHeader) // header
 + order.size() * SIZEOF_RSRC_ICON_GROUP_ENTRY; // entries
+  size_t padding = group_size % sizeof(DWORD);
+  if (padding > 0) {
+padding = sizeof(DWORD) - padding;
+  }
 
-  data_size = group_size // group header
+  data_size = group_size + padding // group header
 + sizeof(DWORD) * 2 // offset and size of group header
 + (sizeof(DWORD) * 2) * icon2.size() // offset and size per entry
 + sizeof(DWORD); // terminator
@@ -358,13 +362,16 @@
   LPBYTE seeker = uninst_data;
 
   // fill group header
-  *(LPDWORD) seeker = FIX_ENDIAN_INT32((UINT32)group_size);
+  *(LPDWORD) seeker = FIX_ENDIAN_INT32((UINT32)(group_size + padding));
   seeker += sizeof(DWORD);
   *(LPDWORD) seeker = 0;
   seeker += sizeof(DWORD);
 
   memcpy(seeker, group, group_size);
   seeker += group_size;
+  for (;padding > 0; padding--) {
+*(seeker++) = '\0';
+  }
 
   // fill entries
   for (i = 0; i < icon2.size(); i++)

Bug#806036: Privilege escalation and code execution vulnerabilities in generated NSIS installers

[Thomas Gaugler]

Thank you very much for your detailed bug report.

I would propose to wait for the review and the fix going in upstream.
Thereafter the fix could be back ported to the NSIS version distributed
by Debian.

Best regards,
Thomas

Bug#778029: nsis: ftbfs with GCC-5

[Thomas Gaugler]

I tried to reproduce the reported errors utilizing cowbuilder.

Therefore I created a cowbuilder chroot environment containing the gcc-5
and g++-5 packages. I used the Debian Stretch (testing) distribution
as basis.

sudo cowbuilder --create --distribution stretch --basepath
/var/cache/pbuilder/base-stretch.cow

sudo cowbuilder --login --distribution stretch --basepath
/var/cache/pbuilder/base-stretch.cow --save-after-login

# aptitude install g++-5
# cd /usr/bin
# ln -sf gcc-5 gcc
# ln -sf g++-5 g++
# exit

I patched the debian/rules Makefile of the nsis (2.46-10) package in
order to output the deployed compilers.

diff --git a/debian/rules b/debian/rules
index a2ab168..1aef7f1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -127,6 +127,8 @@ $(BUILDDIR)/NEWS:
sed -e '0,/^\*\*\*\*\*/c\NSIS Release Notes (automatically
converted from AppendixF.html)' -e 's/F\.[.0-9]* //g' -e 's/^\*\*\*\**
*\([^*]*\)  *\**\*\*\*/\n\1\n/g' -e '/Changelog/d' -e
'/^NSIS_1.x_version_history/,/^=/c\
http://nsis.sourceforge.net/download/nsis1/' -e 's/^\(Released.*\)/
\1\n/g' | cat -s  $@

 override_dh_auto_build-arch: $(BUILDDIR)/NEWS
+   gcc -v
+   g++ -v
scons $(SCONSOPTS_HOST) utils makensis
xmlto -o $(BUILDDIR) man debian/makensis.xml
xmlto -o $(BUILDDIR) man debian/GenPat.xml

Thereafter I issued git-buildpackage:

git-buildpackage --git-verbose --git-pbuilder --git-dist=stretch
--git-cleaner=/bin/true --git-export-dir=../build-area/
--git-tarball-dir=../tarballs/ --git-compression=bzip2 --git-overlay

git-buildpackage succeeded and produced the expected nsis Debian
packages. gcc -v and g++ -v both indicated the following version:
gcc version 5.1.1 20150602 (Debian 5.1.1-9)

Please let me know if I missed some important detail causing a different
result.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754829: [binutils-mingw-w64-i686] i686-w64-mingw32-windres running on s390x does not properly convert string

[Thomas Gaugler]

Package: binutils-mingw-w64-i686
Version: 2.24.51.20140617-1+3
Severity: normal

i686-w64-mingw32-windres running on s390x behaves differently when it
comes to strings.

s390x:
$ echo 'STRINGTABLE { 1, String }' | i686-w64-mingw32-windres

/* Type: stringtable

   Name: 1.  */
LANGUAGE 9, 1

STRINGTABLE MOVEABLE PURE DISCARDABLE
BEGIN
  1, L\x5300\x7400\x7200\x6900\x6e00\x6700
END

amd64:
$ echo 'STRINGTABLE { 1, String }' | i686-w64-mingw32-windres
/* COFF information not part of RC
   Time stamp: 1405365542

   Type: stringtable
   COFF information not part of RC
   Time stamp: 1405365542

   Name: 1
   COFF information not part of RC
   Time stamp: 1405365542.  */
LANGUAGE 9, 1

STRINGTABLE MOVEABLE PURE DISCARDABLE
BEGIN
  1, String
END

I would have expected the same output on the s390x and amd64 system.
It seems the endianness might be the cause of the different behavior.
The s390x architecture uses big endian.

I rebuild the binutils-mingw-w64-i686 debian package to make sure the issue
still occurs in the latest version.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: s390x

Kernel: Linux 3.14-1-s390x (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages binutils-mingw-w64-i686 depends on:
ii  binutils  2.24.51.20140617-1
ii  libc6 2.19-5
ii  zlib1g1:1.2.8.dfsg-1


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704828: nsis: CWD taken from symlink target, not symlink itself

[Thomas Gaugler]

If you provide the -nocd option to makensis then makensis won't change
the current directory to that of the .nsi file.

Below is an example to illustrate it:
cd /tmp
mkdir -p minimal/folder
cat  EOF  minimal/folder/minimal.nsi
!system pwd
OutFile minimal.exe
Section
SectionEnd
EOF
cd minimal
ln -s folder/minimal.nsi
makensis minimal.nsi
 ...
 Changing directory to: /tmp/minimal/folder

 Processing script file: minimal.nsi
 !system: pwd
 /tmp/minimal/folder
 !system: returned 0
 ...
cd folder
makensis minimal.nsi
 same output as above
cd ..
makensis -nocd minimal.nsi
 ...
 Processing script file: minimal.nsi
 !system: pwd
 /tmp/minimal
 !system: returned 0
 ...


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704828: nsis: CWD taken from symlink target, not symlink itself

[Thomas Gaugler]

Good point!

I extended your example by an include directive such as:

tmp/folder/Makefile
---
include folder/hello

all:
pwd
---

tmp/folder/hello
---
hello:
echo Hello World!
---


I consider the include directive in a Makefile as an equivalent to the
LicenseText command
(file:///usr/share/doc/nsis/Docs/Chapter4.html#4.8.1.26) in a .nsi script.

The !insertmacro MUI_PAGE_LICENSE folder/COPYING is going to be
expanded and the expansion amongst others include the command
LicenseText folder/COPYING. So the include folder/hello in the above
Makefile would be the equivalent of LicenseText folder/COPYING
respectively !insertmacro MUI_PAGE_LICENSE folder/COPYING in your .nsi
script.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704828: nsis: CWD taken from symlink target, not symlink itself

[Thomas Gaugler]

If you build your .nsi script in the /home/user/project folder then it
is going to fail as well.

makensis follows symbolic links. So if you put your .nsi file in the
parent folder then you would need to adapt the file references to this
new base (/home/user/project).

In your example this means the following adaption:
---
!insertmacro MUI_PAGE_LICENSE folder/COPYING



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654380: AW: Re: Bug#654380: #654380 (was: nsis: The zmemcpy patch breaks NSISdl::download (at least).)

[Thomas Gaugler]

Please add the Origin field as suggested by you and go ahead with the
upload.

I don't have any further things to be added for your upload.

Thanks in advance and as well a Happy New Year,
Thomas



Didier Raboud o...@debian.org hat geschrieben:


On Tue, 3 Jan 2012 19:43:42 +0100, Thomas Gaugler wrote:


  Thomas: do you have other things you want in before I can upload nsis with
 that change ?


 For completeness the reference to the upstream bug report
 Forwarded: 
 http://sf.net/support/tracker.**php?aid=3406350http://sf.net/support/tracker.php?aid=3406350
 could be added to the debian/patches/static-libgcc-**libstdc++.patch file.


Good point. Although I will add an Origin: upstream, url field, sounds
more realistic (as I did not create the patch and forwarded it there,
rather I picked it from there).

 Thanks a lot for doing the research and taking care of the issue.


No problem. :-

Lemme just repeat my above question: can I go ahead with an upload
containing that or do you want others things in before?

Cheers (and a happy new year),

OdyX

Bug#654380: #654380 (was: nsis: The zmemcpy patch breaks NSISdl::download (at least).)

[Thomas Gaugler]

Hi Odyx,

 This seems to correspond to RedHat's [RH#734905] and to NSIS's
 [NSIS#3406350].

 It works indeed. And the patch is shipped since multiple releases in Fedora,
 so I pushed it to nsis' packaging repository:

 http://anonscm.debian.org/gitweb/?p=collab-maint/nsis.git;a=commit;h=f89eb1af

 Thomas: do you have other things you want in before I can upload nsis with
 that change ?

For completeness the reference to the upstream bug report
Forwarded: http://sf.net/support/tracker.php?aid=3406350
could be added to the debian/patches/static-libgcc-libstdc++.patch file.

Thanks a lot for doing the research and taking care of the issue.

Best regards,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#642756: Fixing RCs #634405 and #642756

[Thomas Gaugler]

Hi OdyX,

 it seems like neither you nor me can find a proper solution to solve
 the parallel building problems highlighted by bugs #634405 and
 #642756. Hence, I propose to simply drop parallel building support,
 with the attached patch.
 
 What do you think ?

On one hand we could drop the parallel building support but on the
other hand we would limit those who try out massive parallel building.

An even simpler solution would be by not passing on 
DEB_BUILD_OPTIONS=parallel=n from the caller program, e. g. omitting
-jn from dpkg-buildpackage.

Furthermore I am not even sure if the issues are actually caused by
the parallel building. I also experienced failures during the test stage
in case of non-parallel building, although these failures only occurred
very rarely. As far as I recall a mismatch of the calling
convention (stdcall) was identified by me as likely candidate for the
failures. I would need to dig out the change from the experimental
unicode patch pushed into the git repository.

So I tend more to keep the parallel building support. However I am
undecided. 

Best regards,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#642756: nsis: FTBFS: sh: 1: .test/makensis: Text file busy

[Thomas Gaugler]

Hi,

It looks like this time the build got past the build failure as
described in bug #634405.

At the moment I have got no plausible explanation about the Text file
busy errors.  Do these errors happen reproducible?

Best regards,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#634405: nsis: FTBFS: i686-w64-mingw32-gcc: error: Source/bzip2/bzlib.c: No such file or directory

[Thomas Gaugler]

It would be interesting to know if similar effects as described in bug
#632228 could be observed. Does a non-parallel build fail as well?

The Source/bzip/bzlib.c file is included in the .orig tarball. So the
file should be there when building.

Best regards,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630620: nsis: Fails to install on the first try

[Thomas Gaugler]

Thanks for pointing out the issue of overwriting files caused by the split 
of the nsis package into four packages.

I added Replaces/Breaks against nsis to the new packages and committed
these changes to the git repository:
http://anonscm.debian.org/gitweb/?p=collab-maint/nsis.git

Best regards,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#620099: nsis: diff for NMU version 2.46-3.1

[Thomas Gaugler]

Hi Stephen,

I combined the best of your patch and the input from
http://sourceforge.net/support/tracker.php?aid=2949102.

The result is now visible in the collab-maint subversion repository.
http://svn.debian.org/wsvn/collab-maint/ext-maint/nsis/trunk/?op=log

The preference is given to mingw-w64. However in case mingw-w64 is not
available then the build process would fall back to mingw32.

So building nsis with mingw-w64 should be officially possible once
nsis-2.46-4 is released.

Your work for mingw-w64 is very much appreciated. Thanks a lot for that.

Best regards,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#620099: nsis: diff for NMU version 2.46-3.1

[Thomas Gaugler]

Hi Stephen,

Thanks for the patch. I am unsure if I could completely drop support
for mingw32 as your patch suggests.
The win32-loader package uses mingw32 as a compiller and requires the
NSIS plugin api header and
library files for mingw32.

Best regards,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#620099: nsis: support building with mingw-w64

[Thomas Gaugler]

Hi Stephen,

Thanks for your patch. I am going to combine your patch with the
information provided in the sourceforge tracker:
http://sourceforge.net/support/tracker.php?aid=2949102

One open issue is where to install the header and library
files for the plugin development. Currently the
paths /usr/i586-mingw32msvc/include respectively
/usr/i586-mingw32msvc/lib are used for that. In my opinion it should
follow the Multiarch approach (http://wiki.debian.org/Multiarch).
However I have not yet figured out how to implement this for win32.

Best regards,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619488: nsis: Please upload an upstream snapshot (Unicode support, more languages, …)

[Thomas Gaugler]

Hi OdyX,

Thanks a lot for your suggestions and feedback. I am exploring if a
full build could be limited to one architecture (i386) and for all
other architectures the architecture independent packages could be
reused.

So far I have not completely succeeded to build nsis from the
subversion repository.

Best regards,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619488: nsis: Please upload an upstream snapshot (Unicode support, more languages, …)

[Thomas Gaugler]

Hi OdyX,

 Given the lack of proper NSIS releases, but given the improvements
 made in their VCS, I think it would be nice to have a more recent
 nsis, a snapshot from their SVN.

That's a good idea and it is also on my mind for sometime. However
before I move onto that I would like to lay the foundation for it.

This means spitting the NSIS package into smaller packages to reduce
the load on the build servers for the different architectures and
make sure installer packages can be build on any Debian architecture
with NSIS.

I thought about splitting the NSIS package into:
* compiler and utils (architecture dependent)
* plugins, stubs and resource files (architecture independent - win32)
* plugin development kit (architecture independent - win32)
* documentation and examples (architecture independent)

Unfortunately there would be a circular dependency for running the
tests during the package building. The NSIS compiler (makensis)
would need the plugins, stubs and resource package during the test
stage. So I am currently investigating how this issue could be solved
best. Any suggestions in this matter are very welcome.

Another advantage of the package splitting would be to have two sets of
plugins/stubs packages for unicode and multibyte character support.

Best regards,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#609781: nsis: FTBFS on i386: E: Caught signal 'Terminated': terminating immediately

[Thomas Gaugler]

 your package FTBFS on i386 in experimental, apparently with a timeout:
 ...
 | /build/buildd-nsis_2.46-3-i386-Xh5JX8/nsis-2.46/build/release/tests/test
 | E: Caught signal 'Terminated': terminating immediately | make[1]:
 ...
 scons: building terminated because of errors. | scons:
 writing .sconsign file. | Build killed with signal TERM after 150
 minutes of inactivity

It failed in the test stage. The reasons why the test executable got
stuck on the build machine are unclear to me. Unfortunately I don't have
access to the build machine for investigating this issue any further.

Fortunately the rebuild triggered by you went through fine.

Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#598039: [p-a-s]: Please remove architecture restrictions on experimental for NSIS

[Thomas Gaugler]

Package: buildd.debian.org
Severity: minor

Please remove the current architecture restrictions on the experimental
repository for the NSIS package.

The source code of NSIS should allow to build for any architecture.

Thanks in advance,
Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#596894: nsis: provide binary package on powerpc

[Thomas Gaugler]

There should no longer be any reasons to restrict the target
architectures for the NSIS package.

I am going to remove the architecture restrictions.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#580957: nsis: Lacks Dzongkha Language files

[Thomas Gaugler]

There does not seem to be a Windows codepage representing the
Dzongkha language.
Source: http://www.microsoft.com/globaldev/reference/WinCP.mspx

Therefore I assume we would need to wait for Unicode NSIS.
http://bugs.debian.org/489374



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#579407: nsis: zlib compression does not work

[Thomas Gaugler]

I plan to apply the following patch to fix the issue.

Description: Make NSIS embedded inflate function compatible with zlib
 The NSIS implementation of deflate deviates from the original one that
 it omits 2 bytes (NLEN - the one's complement of the number of data
 bytes in the block) in the header of each non-compressed block (BTYPE=00). 
 [For details see section 3.2.4 in RFC 1951].
Forwarded: http://sf.net/support/tracker.php?aid=2995455
Bug-Debian: http://bugs.debian.org/579407
Author: Thomas Gaugler tho...@dadie.net

Index: nsis-2.46/Source/zlib/INFBLOCK.C
===
--- nsis-2.46.orig/Source/zlib/INFBLOCK.C
+++ nsis-2.46/Source/zlib/INFBLOCK.C
@@ -424,7 +424,7 @@
   }
   break;
 case LENS:
-  NEEDBITS(16)
+  NEEDBITS(32)
   s-sub.left = (uInt)b  0x;
   b = k = 0;  /* dump bits */
   Tracev((stderr, inflate:   stored length %u\n, s-sub.left));



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#579407: nsis: zlib compression does not work

[Thomas Gaugler]

Thank you very much for your detailed bug report.

The same effects could also be observed on Debian squeeze/sid i386.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#538762: correlation with plugin size?

[Thomas Gaugler]

Download win32-loader package (Lenny):
http://mirrors.kernel.org/debian/pool/main/w/win32-loader/win32-loader_0.6.10_all.deb

Extract systeminfo.dll from win32-loader package via 7-Zip:
7z e win32-loader_0.6.10_all.deb data.tar.gz
7z e data.tar.gz
7z e -r data.tar win32-loader.exe
7z e -r win32-loader.exe systeminfo.dll

Execute the following command on Windows 98 Second Edition:
C:\win32-loader getfunc systeminfo.dll hostname
LoadLibrary of systeminfo.dll failed: 0x001F

= I conclude that the problem just went through unrecognized for
previous versions of the win32 loader package.

The g_stringsize oddity is not needed. The code could be rewritten as below.
Another option is that you call the Win32 API functions
and determine the CPU architecture via the System plugin.
[http://forums.winamp.com/showthread.php?postid=2554554#post2554554]
As a consequence you won't need a win32 loader NSIS plugin.

...

char buf[1024];

void computername (COMPUTER_NAME_FORMAT format, HWND hwndParent, int
string_size, char *variables, stack_t **stacktop, extra_parameters
*extra)
{
EXDLL_INIT();
BOOL result;
DWORD dwStringSize = sizeof(buf) / sizeof(*buf);
typedef BOOL (WINAPI *pfGCNE)(COMPUTER_NAME_FORMAT, LPTSTR, LPDWORD);
pfGCNE GetComputerNameExFunc = (pfGCNE)
GetProcAddress(GetModuleHandleA(kernel32.dll),
GetComputerNameExA);

if (GetComputerNameExFunc)
{
result = GetComputerNameExFunc(format, buf, dwStringSize);
}
else
{
if (ComputerNameDnsHostname == format)
{
result = GetComputerNameA(buf, dwStringSize);
}
else
{
result = 0;
}
}
pushstring(buf);
wsprintf(buf, %u, result);
pushstring(buf);
}



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#538762: correlation with plugin size?

[Thomas Gaugler]

The GetComputerNameEx API function is not available on Windows 9x. As a result
the LoadLibrary API function loading the win32-loader plugin dll fails because
the reference of GetComputerNameExA in the import table could not be resolved
on Windows 9x.

The would propose the attached patch to fix this issue.

GetComputerNameExA API function is not available on Windows 9x kernel32.dll
--- win32-loader/plugins/systeminfo/systeminfo.c.orig	2009-12-02 11:42:33.0 +0100
+++ win32-loader/plugins/systeminfo/systeminfo.c	2009-12-09 18:07:43.0 +0100
@@ -32,9 +32,25 @@
 	BOOL result;
 	DWORD dwStringSize = g_stringsize;
 	stack_t *th;
+	typedef BOOL (WINAPI *pfGCNE)(COMPUTER_NAME_FORMAT, LPTSTR, LPDWORD);
+	pfGCNE GetComputerNameExFunc = (pfGCNE) GetProcAddress(GetModuleHandleA(kernel32.dll), GetComputerNameExA);
 	if (!g_stacktop) return;
 	th = (stack_t*) GlobalAlloc(GPTR, sizeof(stack_t) + g_stringsize);
-	result = GetComputerNameExA(format, th-text, dwStringSize);
+	if (GetComputerNameExFunc)
+{
+		result = GetComputerNameExFunc(format, th-text, dwStringSize);
+	}
+	else
+	{
+		if (ComputerNameDnsHostname == format)
+		{
+			result = GetComputerNameA(th-text, dwStringSize);
+		}
+		else
+		{
+			result = 0;
+		}
+	}	
 	th-next = *g_stacktop;
 	*g_stacktop = th;
 	wsprintf(buf, %u, result);

Bug#538762: correlation with plugin size?

[Thomas Gaugler]

There is a problem loading the win32-loader (SVN rev. 61594) plug-in
via the LoadLibrary API function on Windows 98 Second Edition. I have
not yet found out why the win32-loader plug-in behaves different on
Windows 98 Second Edition compared to other NSIS plug-ins.

Below are my notes regarding the analysis:

Building win32-loader plug-in on Linux Sid:
svn co svn://svn.debian.org/d-i/trunk/win32-loader -r 61594
cd win32-loader
i586-mingw32msvc-gcc -Os plugins/cpuid/cpuid.c plugins/cpuid/plugin.c
plugins/systeminfo/systeminfo.c plugins/string.c
-Wl,--file-alignment,512 -Werror -D_WIN32_WINNT=0x0500
-L/usr/i586-mingw32msvc/lib/nsis -lpluginapi -shared -o
plugins/win32-loader.dll

Evaluating of resulting win32-loader.dll on Windows 98 Second Edition:
C:\win32-loader getfunc win32-loader.dll get_arch
LoadLibrary of win32-loader.dll failed: 0x001F

= ERROR_GEN_FAILURE 31 (0x1F) - A device attached to the system is
not functioning.

in comparison System plug-in from nsis-2.45-1 shows the following result:
C:\win32-loader getfunc System.dll Call
Call function address in System.dll: 0x6E3C301E

Source code of getfunc.c
#include windows.h
#include stdio.h

int main(int argc, char *argv[])
{
   HINSTANCE hInstLib;

   if (3 != argc)
   {
  printf(usage: %s dll function\n, argv[0]);
   }
   else
   {
  hInstLib = LoadLibrary(argv[1]);
  if (NULL != hInstLib)
  {
 printf(%s function address in %s: 0x%08X\n, argv[2],
argv[1], (unsigned int) GetProcAddress(hInstLib, argv[2]));
 FreeLibrary(hInstLib);
  }
  else
  {
 printf(LoadLibrary of %s failed: 0x%08X\n, argv[1],
(unsigned int)GetLastError());
  }
   }
   return 0;
}



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#443121: nsis: NSISdl et al. trigger anti-virus false positives

[Thomas Gaugler]

Package: nsis
Version: 2.45-1

The online virus scan service http://www.virustotal.com did not report any
viruses, worms or trojans on the NSISdl.dll file included in the
nsis_2.45-1_i386.deb package:

 Antivirus Version Last Update Result
 TrendMicro8.950.0.10942009.08.24  -

Therefore I would conclude that the reported problem no longer exists.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#538762: results from plugin are corrupted

[Thomas Gaugler]

I built the installer executable from the sources [testcase.tar.gz]
provided in your bug report on Debian Sid (i386).

The installer correctly showed the following information in a message box:
---
Name Setup
---
arch=amd64
---
OK
---

on a PC running (taken from msinfo32.exe):
OS Name   Microsoft Windows XP Professional
Version   5.1.2600 Service Pack 2 Build 2600
Processor x86 Family 6 Model 15 Stepping 6 GenuineIntel ~1997 Mhz
[refers to a Intel(R) Core(TM)2 CPU  T7200  @ 2.00GHz processor].

Furthermore the installer showed the correct information [arch=i386] 
running on Windows XP in qemu.

The NSIS provided plugins include the compiler option 
-DNSISCALL= __attribute__((__stdcall__)) as you could see from
the following build log: 
https://buildd.debian.org/fetch.cgi?pkg=nsisarch=i386ver=2.44-4stamp=1237526925file=logas=raw

Beside that I did not spot any other potential problem with
the win32-loader plugin code.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#319999: porting asm to gcc

[Thomas Gaugler]

Hi Pabs,

I come back to your offer to figure out the scons side.

The attached patch (against nsis-2.40) implements the 
functions CallProc, RealCallBack and CallBack of the System 
plugin in pure x86 assembly. The call.asm assembly source 
file supports both the MASM and GNU assembler in one file. 
The trick lies in the ; .if 0 line which is ignored by 
MASM but evaluated by the GNU assembler.

The stack probing function _alloca_probe is equivalent
to _chkstk. GCC provides an equivalent function in
libgcc called _alloca. For details see the discussion
in:
http://gcc.gnu.org/ml/gcc/2006-11/msg00081.html

I refrained from using hardcoded offsets for the structures
SystemProc and ProcParameter but rather opted for C helper
functions for determining these offsets. As a result it is 
easier for maintenance because changes to the SystemProc 
and ProcParameter structures would not affect the assembly 
source code. As a side effect the hardcoded offset 
SYSTEM_ZERO_PARAM_VALUE_OFFSET in System.h is no longer
needed.

I changed the macros SYSTEM_LOG_ADD and SYSTEM_LOG_POST in
System.c to avoid an access violation in case call.asm was 
compiled without the SYSTEM_DEBUG_LOG define. 

DllMain is used instead of _DllMainCRTStartup to avoid an
endless recursion for the debug report macro _RPT0. The 
system DllMain initializes the C runtime environment. In 
particular the value for _osplatform is initialized. In the
function _get_winmajor called in the execution of the _RPT0 
macro an assertion failure is raised if _osplatform is 
not set. The assertion is reported by the same means as 
used for the _RPT0 macro. This leads to an endless
recursion. By default the define SYSTEM_DEBUG_LOG is not
set. So it would be ok to stick with _DllMainCRTStartup.

I used the attached test.py python script for unit 
testing the System plug-in.

For building the System plug-in I used the development
environment of Microsoft Visual Studio 8 and the
following batch script for the GNU toolchain:

@echo off
setlocal
set TOOLCHAIN_PATH=C:\mingw\bin
rem SET DEBUG=-DSYSTEM_DEBUG_LOG
set DEFINES=-DWIN32 -DNDEBUG -D_WINDOWS -D_USERDLL %DEBUG%
set CFLAGS=-g -Os -Wall %DEFINES%

set SRCS=Buffers.c Plugin.c stdafx.c System.c
set ASM_SRCS=call.asm
set OBJS=Buffers.o call.o Plugin.o stdafx.o System.o

et AS=%TOOLCHAIN_PATH%\gcc.exe -x assembler-with-cpp -s
set GCC=%TOOLCHAIN_PATH%\gcc.exe

for %%F in (%SRCS%) do %GCC% %CFLAGS% -c %%F
for %%F in (%ASM_SRCS%) do %AS% %DEFINES% -c %%F

%GCC% -shared %OBJS% -mwindows -o System.dll -lole32 -Wl,--add-stdcall-alias
enlocal

So that's where scons respectively you are welcome to 
take over.

Best regards,
Thomas
diff -urN nsis-2.40-src.orig/Contrib/System/Source/call.asm nsis-2.40-src/Contrib/System/Source/call.asm
--- nsis-2.40-src.orig/Contrib/System/Source/call.asm	1970-01-01 01:00:00.0 +0100
+++ nsis-2.40-src/Contrib/System/Source/call.asm	2008-10-24 20:15:22.0 +0200
@@ -0,0 +1,954 @@
+;# Copyright (c) 2008 Thomas Gaugler [EMAIL PROTECTED]
+;#
+;# Permission is hereby granted, free of charge, to any person
+;# obtaining a copy of this software and associated documentation
+;# files (the Software), to deal in the Software without
+;# restriction, including without limitation the rights to use,
+;# copy, modify, merge, publish, distribute, sublicense, and/or sell
+;# copies of the Software, and to permit persons to whom the
+;# Software is furnished to do so, subject to the following
+;# conditions:
+;#
+;# The above copyright notice and this permission notice shall be
+;# included in all copies or substantial portions of the Software.
+;#
+;# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+;# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+;# OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+;# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+;# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+;# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+;# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+;# OTHER DEALINGS IN THE SOFTWARE.
+;#
+;#
+;# Implementation of the functions CallProc, RealCallBack and
+;# CallBack of the System plugin in pure x86 assembly.
+;#
+;# This is a hybrid assembly source file supporting both the
+;# MASM as well as the GNU assembler in one file.
+;#
+;# 
+;# MASM:
+;# ml.exe /c /nologo /Focall.obj /W3 /Zi /errorReport:prompt /Tacall.asm
+;#
+;# For enabling debug support use:
+;# ml.exe /c /nologo /DSYSTEM_DEBUG_LOG /Focall.obj /W3 /Zi /errorReport:prompt /Tacall.asm 
+;#
+;# GNU toolchain:
+;# gcc -x assembler-with-cpp -s call.asm -c
+;# 
+;# For enabling debug support use:
+;# gcc -x assembler-with-cpp -DSYSTEM_DEBUG_LOG -s call.asm -c
+;#
+
+; .if 0
+;# MASM specific block
+.386
+.model flat
+OPTION casemap:none
+;# SYSCALL is identical to the C calling convention, 
+;# but does not add an underscore prefix to symbols.
+OPTION language:syscall
+
+SECTION_DATA equ