Test PROGRAM Format=PE reports E6101

[vitsoft]

Thank you. Already done. Now onto the next problem:

;===================================================================================== HEADER
EUROASM CPU=X64, AMD=ON
Test PROGRAM Format=PE, Subsystem=GUI, WIDTH=64, Entry=START
INCLUDE winabi.htm, wins.htm, winsgui.htm, fastcall.htm, cpuext.htm, cpuext64.htm

Gives the following errors:

I0010 EuroAssembler version 20180804 started.
I0020 Current directory is "E:\Archives\0~~\Experimental".
I0070 Assembling global option file "E:\Archives\0~~l\euroasm.ini".
I0170 Assembling local option file "euroasm.ini".
I0180 Assembling source file "Test.asm".
I0270 Assembling source "Test".
I0310 Assembling source pass 1.
W3740 Unknown instruction modifier "Subsystem=". Ignored. "Test.asm"{3}
W3740 Unknown instruction modifier "WIDTH=". Ignored. "Test.asm"{3}
W3740 Unknown instruction modifier "Entry=". Ignored. "Test.asm"{3}
E6101 Expression "PROGRAM " is followed by unexpected character "F". "Test.asm"{3}

Also, skelet64.htm has two copies of INVOKE winsgui.htm in the header.

The statement Test PROGRAM Format=PE, Subsystem=GUI, WIDTH=64, Entry=START was parsed differently than its author intended.
When the statement starts with a valid machine instruction/pseudoinstruction/macroinstruction, StmParse thinks that this statement has no label, and treats the recognized instruction (Test) as operation field. Remedy is simple: avoid symbol|proc|program names which collide with existing instructions, or terminate the name with a colon: Test: PROGRAM Format=PE, Subsystem=GUI, WIDTH=64, Entry=START

Ad double inclusion of "winsgui.htm" in skelet64:
you are right, the 2nd INCLUDE shouldn't name it (unless we'd used INCLUDE1 instead of INCLUDE).
The weird thing is that it assembles without error, though. Putting %DISPLAY Files in front of ENDPROGRAM skelet64 divulged that the file is in fact loaded only once. I'll have a look at this later.

BTW I0010 EuroAssembler version 20180804 is obsolete, see https://euroassembler.eu/download/

[ar18]

Thank you. Already done. Now onto the next problem:

The statement Test PROGRAM Format=PE, Subsystem=GUI, WIDTH=64, Entry=START was parsed differently than its author intended.

When the statement starts with a valid machine instruction/pseudoinstruction/macroinstruction, StmParse thinks that this statement has no label, and treats the recognized instruction (Test) as operation field. Remedy is simple: avoid symbol|proc|program names which collide with existing instructions, or terminate the name with a colon: Test: PROGRAM Format=PE, Subsystem=GUI, WIDTH=64, Entry=START

I like easy problems with easy solutions

Also, skelet64.htm has two copies of INVOKE winsgui.htm in the header.

Ad double inclusion of "winsgui.htm" in skelet64:
you are right, the 2nd INCLUDE shouldn't name it (unless we'd used INCLUDE1 instead of INCLUDE).
The weird thing is that it assembles without error, though. Putting %DISPLAY Files in front of ENDPROGRAM skelet64 divulged that the file is in fact loaded only once. I'll have a look at this later.

I cut and pasted the header from skelet64.html into Test.asm when I couldn't get it to assemble, and I had one error ... something about trying to redefine a certain variable of some kind. Sorry I didn't take note of the error because I wasn't sure if the problem was me or a bug, and I didn't want to jump to conclusions.

[vitsoft]

Mystery with duplicated INCLUDE winsgui.htm explained:
The library belongs to PROGRAM realm, which means that it contains only constant symbols and structures definitions (not macros).
The second INCLUDE is encapsulated in PROGRAM..ENDPROGRAM block, and when assembly of PROGRAM starts, it begins with empty symbol table, no symbols|structures are inherited from outside. That is why the symbols and structures included on the 3rd source line are not visible for skelet64 PROGRAM and their repeated inclusion in the same source does not report E6610 Symbol "!1S" was already defined.