Does it require a new version of the 64-bit SDK?
An include \masm32\include64\GdiPlus.inc solves many of the errors below, but for example, invoke button,hInstance chokes because button is undefined.
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: controls.asm
controls.asm(33) : error A2006:undefined symbol : GdiplusStartup
procedure_call(19): Macro Called From
invoke(1): Macro Called From
GdiPlusBegin(9): Macro Called From
controls.asm(33): Main Line Code
controls.asm(44) : error A2006:undefined symbol : GdiplusShutdown
procedure_call(11): Macro Called From
invoke(1): Macro Called From
GdiPlusEnd(1): Macro Called From
controls.asm(44): Main Line Code
controls.asm(167) : error A2006:undefined symbol : button
procedure_call(41): Macro Called From
invoke(1): Macro Called From
controls.asm(167): Main Line Code
... etc
This is the build I get using the same files.
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: controls.asm
Microsoft (R) Incremental Linker Version 14.10.24930.0
Copyright (C) Microsoft Corporation. All rights reserved.
Volume in drive K is disk3_k
Volume Serial Number is 68C7-4DBB
Directory of K:\asm64\asm2\controls
03/01/2017 08:03 PM 8,899 controls.asm
03/01/2017 10:30 PM 13,312 controls.exe
03/01/2017 10:30 PM 9,978 controls.obj
03/01/2017 08:05 PM 13,445 controls.zip
4 File(s) 45,634 bytes
0 Dir(s) 972,839,194,624 bytes free
Press any key to continue . . .
Have you modified anything at all in the setup ?
See if you have these 2 macros at the end of the macros file.
GdiPlusBegin MACRO ;;;; token
.data
gdii GdiplusStartupInput <>
GDItoken@@@@ dq ?
.code
mov gdii.GdiplusVersion, 1
mov gdii.DebugEventCallback, 0
mov gdii.SuppressBackgroundThread, 0
mov gdii.SuppressExternalCodecs, 0
invoke GdiplusStartup,ADDR GDItoken@@@@,ADDR gdii,0
ENDM
GdiPlusEnd MACRO ;;;; token
invoke GdiplusShutdown,GDItoken@@@@ ; cleanup on exit
ENDM
The attachment will update the missing files. Latest macro file and all of the current library modules.
Quote from: hutch-- on March 01, 2017, 10:32:34 PMHave you modified anything at all in the setup ?
I just downloaded the latest SDK64 from http://masm32.com/board/index.php?topic=5631.0 and installed it, still the same issues. Will try the macros now.
EDIT: Opened the attachment above, overwrote all m64lib files and macros, and now it builds but doesn't show any controls.
Perhaps you should mention that the SDK is out of date.
> Perhaps you should mention that the SDK is out of date.
It tends to be unfinished. I am surprised about the controls, the modules are in the library code and they are called in the supplied source. Its a reasonably tedious task to make temporary installations so I have not madly hurried at producing them.
I just checked, the macro file was posted at this URL.
http://masm32.com/board/index.php?topic=5918.0
Its the same one as in the zip file above.
Quote from: jj2007 on March 01, 2017, 10:55:12 PMit builds but doesn't show any controls.
The exe in controls.zip in your initial post above shows various controls. The rc, however, has only the menu and the VCB. And there are only two CreateWindowEx (main win, static) in the source...
P.S.:
.case 300
int 3
invoke MsgboxI,hWin, \
"Using the old style windows controls.", \
"About Window Controls Demo",MB_OK,10The int 3 is triggered, so the command is being executed, but the MsgBox doesn't show :(
The controls are in the library I posted in this thread. button, listbox etc ...
That's the one I am using :(
With ...
int 3
invoke button,hInstance,hWin,"Button1",blft,btop,bwid,bhgt,601
nop
... I can see this in the debugger:0000000140001461 | CC | int3 |
0000000140001462 | 48 8B 0D B7 27 00 00 | mov rcx, qword ptr ds:[140003C20] |
0000000140001469 | 48 8B 55 10 | mov rdx, qword ptr ss:[rbp+10] |
000000014000146D | 4C 8B 05 64 1D 00 00 | mov r8, qword ptr ds:[1400031D8] | 1400031D8:&"Button1"
0000000140001474 | 49 C7 C1 19 00 00 00 | mov r9, 19 |
000000014000147B | 48 C7 44 24 20 14 00 00 00 | mov qword ptr ss:[rsp+20], 14 |
0000000140001484 | 48 C7 44 24 28 6E 00 00 00 | mov qword ptr ss:[rsp+28], 6E | 6E:'n'
000000014000148D | 48 C7 44 24 30 19 00 00 00 | mov qword ptr ss:[rsp+30], 19 |
0000000140001496 | 48 C7 44 24 38 59 02 00 00 | mov qword ptr ss:[rsp+38], 259 | [rsp+38]:UpdateLayeredWindowIndirect+2B9
000000014000149F | E8 1C 08 00 00 | call 140001CC0 |
00000001400014A4 | 90 | nop |
Result is 0, error_bad_exe_format
This is on Win7-64.
Win 7 64bit Ultimate.
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: controls.asm
Microsoft (R) Incremental Linker Version 14.00.23506.0
Copyright (C) Microsoft Corporation. All rights reserved.
Volume in drive M is disk4_m
Volume Serial Number is BE9E-CF66
Directory of M:\controls
03/01/2017 09:03 PM 8,899 controls.asm
03/02/2017 01:44 AM 13,312 controls.exe
03/02/2017 01:44 AM 9,966 controls.obj
03/01/2017 09:05 PM 13,445 controls.zip
4 File(s) 45,622 bytes
0 Dir(s) 987,018,883,072 bytes free
Press any key to continue . . .
I have no way of determining how your machine is set up so its nearly impossible to diagnose why builds on your machine don't work.
i just missed 0064.zip
Quote from: hutch-- on March 02, 2017, 01:52:46 AM
I have no way of determining how your machine is set up so its nearly impossible to diagnose why builds on your machine don't work.
It builds fine now, but under the hood of "button" the CreateWindowExA fails with the above mentioned error.
There is something going on that I fail to understand here. Below is a very ordinary API code that builds perfectly and runs normally.
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
include \masm32\include64\masm64rt.inc
.code
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
button proc instance:QWORD,hparent:QWORD,text:QWORD,topx:QWORD,topy:QWORD,wid:QWORD,hgt:QWORD,idnum:QWORD
invoke CreateWindowEx,WS_EX_LEFT,"BUTTON",text, \
WS_CHILD or WS_VISIBLE,\
topx,topy,wid,hgt,hparent,idnum,instance,0
ret
button endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
end
Quote from: hutch-- on March 02, 2017, 10:14:37 AM
There is something going on that I fail to understand here.
Me too. I've compared the original exe (which shows controls) to the ones I built here using PEview - see attachment. Code sections are absolutely identical, but the .rdata sections look different.
I've modified the code so that the About menu entry shows the 601 MessageBox instead. Well,
should show...
0000000140001397 | CC | int3 |
0000000140001398 | 48 8B 4D 10 | mov rcx, qword ptr ss:[rbp+10] |
000000014000139C | 48 8B 15 7F 1D 00 00 | mov rdx, qword ptr ds:[140003122] | 140003122:&"Howdy Howdy Howdy"
00000001400013A3 | 4C 8B 05 8E 1D 00 00 | mov r8, qword ptr ds:[140003138] | 140003138:&"Button1"
00000001400013AA | 49 C7 C1 00 00 00 00 | mov r9, 0 |
00000001400013B1 | FF 15 1D 26 00 00 | call qword ptr ds:[<&MessageBoxA>] |Parameters look ok: rcx=0, r9=0, rdx is "howdy" and r8 is "button1". It returns error_success but
it doesn't show ::)
I have created an equivalent MsgBox which works:
include \Masm32\MasmBasic\Res\JBasic.inc ; ## console demo, builds in 32- or 64-bit mode with ML, AsmC, JWasm, HJWasm ##
Init ; OPT_64 1 ; put 0 for 32 bit, 1 for 64 bit assembly
MsgBox 0, "Wow, it works!!!!", "Hi", MB_OK or MB_SETFOREGROUND
EndOfCode
I followed both versions in the debugger down to the call to MessageBoxTimeoutW. Everything identical except that one shows, the other doesn't. Even handle zero for both MsgBoxes shows the same difference, so hWin is not the culprit.
This is mysterious: Two MessageBoxA calls, with good parameters, one shows up, the other doesn't; both show ERROR_SUCCESS :dazzled:
@Tim: Does your version work?
JJ,
See if this simple MessageBox builds OK in your 64 bit MASM setup. It may help to track down why your builds are not working.
Worked here in Windows 7
smaller
12,5 KB (12 800 bytes)
than original
13,0 KB (13 312 bytes)
so 2015 version put some odd code to it.
EDIT: test was made using version 10 tools.
Thanks Tim, its probably the linker.
Hutch,
The MsgBox builds and runs fine, but the controls example refuses to show the controls, even with recent tools, see screenshot below. I've made a little test: .case 300 ; OPT_Susy console
; int 3
invoke MessageBox, 0, "MsgBox TEXT","MsgBox title", MB_YESNOCANCEL
conout chr$("shown", 13, 10)
With console build, the string "shown" appears, but no MessageBox. As mentioned aboved, I've tracked it down to the point where it enters MessageBoxTimeoutW, and everything was identical to another, working, example.
If I'm really the only one who has this problem, forget it, but given the difficulty of getting the build environment right I suspect that only a handful of people have tested it so far...
P.S.: The altered menu text below is just to verify whether the rc file was processed correctly ;-)
P.P.S.: Gotcha!
I hate manifests! So what happened?
- I open Hutch' archive
- and try to unzip everything to C:\Masm32\MasmBasic\Members\Hutch\
- unzipper says "file exists. Auto rename?" - yessss!
And voilà, Hutch' example gets built with an old x86 manifest.xml
No warning from Micros**t's hyper-advanced tools, of course. But that is the cause of all the problems.
And the solution is easy...
Original manifest.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>Microsoft C Template</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
Heavily modified manifest.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>Microsoft C Template</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
:badgrin:
OK,
So I gather something in your setup modified one of the demo's source file, in this case the manifest, and prevented the demo from building correctly. :idea:
Yes indeed. Problem is that these tools do not even throw a warning, and the error gets thrown deep in the guts of Windows. As shown above, the solution is extremely simple: processorArchitecture=...
What is the gain supposed to be if the original manifest works correctly ? Is this something you should take up with Microsoft ? :shock: It can't be as bad as the low level win64 documentation.
Hutch, you are arguing for the argument's sake. Point is that you can use the same manifest for 32-bit and 64-bit assembly. This one, for example, ships with MasmBasic since December 2016 and works fine with 64-bit code, too:<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>MasmBasic</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
/>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.GdiPlus"
version="1.0.0.0" processorArchitecture="*"
publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
</assembly>
Ha ha, your ideology is getting in the road of your intent. I am not the least interested in multi-port assembler and no amount of trolling will change that. If I want 32 bit assembler, I use the MASM32 project, when I want 64 bit assembler, I use 64 bit MASM. I have no need of the compromises required to marry 2 different architectures together and don't have any of the problems of doing so.
Quote from: hutch-- on March 03, 2017, 05:13:30 PM
Ha ha, your ideology is getting in the road of your intent. I am not the least interested in multi-port assembler and no amount of trolling will change that. If I want 32 bit assembler, I use the MASM32 project, when I want 64 bit assembler, I use 64 bit MASM. I have no need of the compromises required to marry 2 different architectures together and don't have any of the problems of doing so.
+1 :greenclp:
As an aside, you can get link to generate your manifest via the command line without having to use a resource.
Gratsie, that is useful to know.
Quote from: hutch-- on March 03, 2017, 05:50:08 AM
What is the gain supposed to be if the original manifest works correctly ? Is this something you should take up with Microsoft ? :shock:
My dear friends,
I don't quite understand why you are constructing a "troll case" here - seriously? All I've done is to point out, in Reply #16, that by replacing
processorArchitecture="X86"with
processorArchitecture="*"you can use the same manifest for 64-bit and 32-bit code. And that option is not a Windows bug,
it is by design. So why insist that for assembling 64-bit code you need an entirely different set of files? Sure, there are 100 versions of GdiPlus.dll in C:\Windows\System32\ and subfolders, but I don't find that particularly sexy. I love assembly because it's
not bloated.
Quote from: sinsi on March 03, 2017, 08:13:28 PMAs an aside, you can get link to generate your manifest via the command line without having to use a resource.
That sounds interesting but MSDN's Manifest Generation at the Command Line (//http://) is not particularly helpful. Do you have a working example?
It's a bit of a mess (MS documentation ::) ) but I use this
set link= /manifest:embed
set link=%link% /manifestdependency:"type='Win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'"
:: add this for UAC, asInvoker or requireAdministrator for elevation
set link=%link% /manifestuac:"level='asInvoker' uiAccess='false'"
Gets added to the .rsrc section. Seems to work...32 and 64 bit
QuoteAs an aside, you can get link to generate your manifest via the command line without having to use a resource.
Yes or /MANIFESTFILE:filename
Quote from: jj2007 on March 03, 2017, 08:34:36 PM
So why insist that for assembling 64-bit code you need an entirely different set of files?
Different ML, different libraries, different includes...
Quote from: sinsi on March 03, 2017, 08:37:25 PM
Quote from: jj2007 on March 03, 2017, 08:34:36 PM
So why insist that for assembling 64-bit code you need an entirely different set of files?
Different ML, different libraries, different includes...
MSDN: (https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745(v=vs.85).aspx)
QuoteThe header files for the Windows API enable you to create 32- and 64-bit applications. They include declarations for both Unicode and ANSI versions of the API. For more information, see Unicode in the Windows API. They use data types that enable you to build both 32- and 64-bit versions of your application from a single source code base
:biggrin:
What you are not saying is that MSDN comment is for Microsoft C/C++.
> Different ML, different libraries, different includes..
This is the action, Win64 in /LARGEADDRESSAWARE mode is architecturally different to Win32. Entirely different stack layout, mixed register/memory calling convention and some differences in some of the API calls. Multi port assembler is a pipe dream, you can write clear clutter free 64 bit MASM but under the hood its purely 64 bit, no hybrids.
BTW:
about linker commandline
bare /LARGEADDRESSAWARE if for win32 x86.
LARGEADDRESSAWARE is default for win64 x64, so only rare occasions /LARGEADDRESSAWARE:NO is needed.
another thing:
C isn't bloated, CRT is and in early days, lot of it was written in assembly ;)
Quote from: ragdog on March 03, 2017, 08:36:07 PMYes or /MANIFESTFILE:filename
Dangerous option: if you specify an existing file, it gets overwritten!
The right option seems to be /manifest
input:MyFile.xml, but apparently it requires linker version 14, difficult to set up etc, and eventually it will ask you for a non-existent mt.exe :(
EDIT: Finally, I managed to convince LINK 14.0 to perform its task. It's messy, as usual :badgrin:
- the relevant commandline options are
/verbose /manifest:embed /manifestinput:MyFile.xml- you need at least \Masm32\bin\mspdbcore.dll
- the linker will choke unless you move MT.EXE into the bin folder
- if you are lucky, MT.EXE sits in C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\mt.exe
- if you don't like the /verbose option, try without; on my machine, the infamous -ologo error (https://social.msdn.microsoft.com/Forums/en-US/26ca43b4-b2f3-4d2b-aede-ec58501854e4/rc-fatal-error-rc1106-invalid-option-ologo-somebody-help-me-please?forum=vcprerelease) pops up
Anyway, even for X64, polink and a standard XP manifest with processorArchitecture=
"*" works fine :P
JJ,
Herein lies the difference, the manifest in the demo work just fine on my Win10 64 and Win7 64 just as it has for every other EXE that has been built with it and has proven to be reliable. I make no assumptions about cross OS version compatibility and don't need it as 64 bit MASM does not build 16 or 32 bit code, ML.EXE does that fine. I am pleased to hear that you have solved the problem you had with manifests and have a version that works across 32 and 64 bit code but I will make the point again that the one I am using works just fine and I have no need to change it at all.
deleted
@ninud
you are cruel :biggrin:
No support for windows 10 :biggrin:
ml.exe v.14
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"></supportedOS>
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"></supportedOS>
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"></supportedOS>
The following GUIDs correspond with the indicated operating systems:
{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a} -> Windows 10 and Windows Server 2016
{1f676c76-80e1-4239-95bb-83d0f6d0da78} -> Windows 8.1 and Windows Server 2012 R2
{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38} -> Windows 8 and Windows Server 2012
{35138b9a-5d96-4fbd-8e2d-a2440225f93a} -> Windows 7 and Windows Server 2008 R2
{e2011457-1546-43c5-a5fe-008deee3d3f0} -> Windows Vista and Windows Server 2008
deleted