Discussion about Demo of old style controls on a normal window.

[hutch--]

Thanks Tim, its probably the linker.

[jj2007]

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:

Code: [Select]

.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:

Code: [Select]

<?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:

Code: [Select]

<?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>

[hutch--]

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:

[jj2007]

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:

Code: [Select]

processorArchitecture=...

[hutch--]

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.

[jj2007]

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:

Code: [Select]

<?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>

[hutch--]

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.

[sinsi]

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

As an aside, you can get link to generate your manifest via the command line without having to use a resource.

[hutch--]

Gratsie, that is useful to know.

[jj2007]

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

Code: [Select]

processorArchitecture="X86"with

Code: [Select]

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.

As 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 is not particularly helpful. Do you have a working example?

[sinsi]

It's a bit of a mess (MS documentation  ::) ) but I use this

Code: [Select]

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

[ragdog]

As an aside, you can get link to generate your manifest via the command line without having to use a resource.

Yes or /MANIFESTFILE:filename 

[sinsi]

So why insist that for assembling 64-bit code you need an entirely different set of files?

Different ML, different libraries, different includes...

[jj2007]

So why insist that for assembling 64-bit code you need an entirely different set of files?

Different ML, different libraries, different includes...

MSDN:

The 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

[hutch--]

 

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.