How to write Win16 program with only a single segment (combined code+data)?

Question

I wrote a simple Win16 program in NASM assembly. It works on Windows 3.11. (Source code: https://github.com/pts/mininasm/blob/master/demo/hello/helljw16.nasm .)

When I tried to combine the code and data segments to a single segment, it stopped working. I don't get any error message from Windows, but the messagebox doesn't appear. Is it possible to have a combined segment? If so, what's wrong with my code?

Update: Please note that my code has very few read-write variables (currently none, except in registers and on the stack), so it would be OK to keep the read-only variables in the code segment, and use a few bytes of stack (populated manually) for the read-write variables. Thus the data segment entry in SegTab is not strictly necessary. But the program doesn't work without it, and I'm interested if there is a fix.

The relevant part below is after the SegTab label: it contains a definition for a single segment only.

;
; hellhw16.nasm: minimalistic hello-world Win16 Windows 3.0 8086 .exe
; by [email protected] at Tue Dec 20 22:40:03 CET 2022
;
; nasm -O0 -f bin -o helljw16.exe helljw16.nasm
;
; See also: https://github.com/alexfru/Win16asm/blob/master/ne.inc
; See also: https://board.flatassembler.net/topic.php?t=21339
; See also: https://devblogs.microsoft.com/oldnewthing/20071203-00/?p=24323
;

        bits 16
        cpu 8086
        org 0

FILE_ALIGNMENT_SHIFT equ 1

mz_header:  ; DOS .exe header: http://justsolve.archiveteam.org/wiki/MS-DOS_EXE
.signature  db 'MZ'
.lastsize:      dw (.end - .signature) & 0x1ff  ; The value 0 and 0x200 are equivalent here. Microsoft Linker 3.05 generates 0, so do we. Number of bytes in the last 0x200-byte block in the .exe file.
.nblocks:       dw (.end - .signature  + 0x1ff) >> 9  ; Number of 0x200-byte blocks in .exe file (rounded up).
.nreloc     dw 0  ; No relocations.
.hdrsize    dw 0  ; Load .exe file to memory from the beginning.
..@code:
%if 1  ; Produces identical .exe output even if we change it to 0.
.minalloc:  mov ax, 0x903  ; AH := 9, AL := junk. The number 3 matters for minalloc, see below.
.ss_minus_1:    mov dx, .message+(0x100-$$)  ; (0x100-$$) to make it work with any `org'.
.sp:        int 0x21  ; Print the message to stdout. https://stanislavs.org/helppc/int_21-9.html
.checksum:  jmp strict short .do_exit
%else
.minalloc   dw 0x03b8  ; To have enough room for the stack, we need minalloc >= ss+((sp+0xf)>>4)-0x20 == 0x315. kvikdos verifies it.
.maxalloc   dw 0xba09  ; Actual value doesn't matter.
.ss     dw 0x0118  ; Actual value doesn't matter as long as it matches minalloc. dw message
.sp     dw 0x21cd  ; Actual value doesn't matter. int 0x21
.checksum   dw 0x21eb  ; Actual value doesn't matter.
%endif
.ip     dw ..@code+(0x100-$$)  ; Entry point offset. (0x100-$$) to make it work with any `org'.
.cs     dw 0xfff0  ; CS := PSP upon entry.
%if 0
.relocpos   dw ?  ; Doesn't matter, overlaps with 2 bytes of message: 'He'.
.noverlay   dw ?  ; Doesn't matter. overlaps with 2 bytes of message: 'll'.
; End of 0x1c-byte .exe header.
%endif

; OpenWatcom stub message.
.message    db 'This is a Win16 executable.', 13, 10, '$'

.do_exit:   mov ax, 0x4c01  ; Same exit code as in OpenWatcom stub.
        int 0x21

        times 0x3c-($-$$) db 0  ; Pad to 60 bytes.
        dd ne_header-$$
.end:

PFLAG:
.INST       equ 2

AFLAG:
.WINCOMPAT  equ 2

OSFLAG:
.WINDOWS    equ 2  ; Win16.

ne_header:
.Signature  db 'NE'
.LinkerVer  db 5
.LinkerRev  db 1
.EntryTabOfs    dw EntryTab-ne_header
.EntryTabSize   dw EntryTab.end-EntryTab
.ChkSum     dd 0  ; Always 0.
.ProgramFlags   db PFLAG.INST
.ApplicationFlags db AFLAG.WINCOMPAT
.AutoDataSegNo  dw 1
.HeapInitSize   dw 0
.StackSize  dw 0x100
.InitIp     dw _start-segment_code
.InitCsSegNo    dw 1
.InitSp     dw 0
.InitSsSegNo    dw 1
.SegCnt     dw (SegTab.end-SegTab)>>3
.ModCnt     dw (ModRefTab.end-ModRefTab)>>1
.NonResNameTabSize dw NonResNameTab.end-NonResNameTab
.SegTabOfs  dw SegTab-ne_header
.ResourceTabOfs dw ResourceTab-ne_header
.ResNameTabOfs  dw ResNameTab-ne_header
.ModRefTabOfs   dw ModRefTab-ne_header
.ImpNameTabOfs  dw ImpNameTab-ne_header
.NonResNameTabOfs dd NonResNameTab-$$
.MovableEntryCnt dw 0
.SegAlignShift  dw FILE_ALIGNMENT_SHIFT
.ResourceSegCnt dw 0
.OsFlags    db OSFLAG.WINDOWS
.ExeFlags   db 0
.FastLoadOfs    dw 0
.FastLoadSize   dw 0
.Reserved   dw 0
.ExpectedWinVer dw 0x300

$SEG:
.DATA       equ 0x0001
.MOVABLE    equ 0x0010
.SHARABLE   equ 0x0020
.PRELOAD    equ 0x0040
.REL        equ 0x0100
.DPL3       equ 0x0c00
.DISCARDABLE    equ 0x1000

SegTab:
.seg1.fofs  dw (segment_code-$$)>>FILE_ALIGNMENT_SHIFT
.seg1.size  dw segment_code_end-segment_code
.seg1.flags dw $SEG.REL | $SEG.PRELOAD | $SEG.REL | $SEG.DPL3 | $SEG.DATA
.seg1.minalloc  dw segment_code_end-segment_code
.end:

ResourceTab:
.end:

ResNameTab:
.entry0     db .entry0.end-.entry0-3, 'hellnw16', 0, 0  ; Module name.
.entry0.end:
        db 0  ; End of table.
ModRefTab:
.user:      dw ImpNameTab.mod1-ImpNameTab
.kernel:    dw ImpNameTab.mod2-ImpNameTab
.end:

ImpNameTab:
        db 0
.mod1       db .mod1.end-$-1, 'USER'
.mod1.end:
.mod2       db .mod2.end-$-1, 'KERNEL'
.mod2.end:

EntryTab:
        db 0  ; Why?
        db 0
.end:

NonResNameTab:
.entry0:    db .entry0.end-.entry0-3, 'hellnw16.exe', 0, 0  ; Module description.
.entry0.end:
        db 0  ; End of table.
.end:

before_segment_code times ($$-$)&((1<<FILE_ALIGNMENT_SHIFT)-1) db 0
segment_code:
segment_data:
instancedata:
msg_hi      db 'Hi!', 0
        times (instancedata+0xa)-$ db 0
.id0xa      dw 0  ; InitTask overwrites it to stack bottom.
.id0xc      dw 0  ; InitTask overwrites it to stack bottom.
.id0xe      dw 0  ; InitTask overwrites it to stack top.

msg_hello   db 'Hello, World!', 0

_start:     push cs
        pop ds
        xor bp, bp  ; !! Do we need this? Maybe on Windows 3.0? Microsoft libc has it.
        push bp  ; Do we need this? Not on Windows 3.11.
..@reloc1   equ $+1
        call 0:0xffff  ; InitTask. 'INITTASK'.'KERNEL' @91 == @0x5b.
        test ax, ax
        jz strict short .fail
        push di
        db 0x33, 0xc0  ; xor ax, ax
        push ax
..@reloc2   equ $+1
        call 0:0xffff  ; WaitEvent. 'WAITEVENT'.'KERNEL' @30 == @0x1e.
..@reloc3   equ $+1
        call 0:0xffff  ; InitApp. 'INITAPP'.'USER' @5.
        test ax, ax
        jz strict short .fail
        xor ax, ax
        push ax
        push ds
        mov bx, msg_hello-segment_data
        push bx
        push ds
        mov bx, msg_hi-segment_data
        push bx
        push ax
..@reloc0   equ $+1
        call 0x0:0xffff  ; MessageBox. 'MESSAGEBOX'.'USER' @1. !! Why is segment -0?
        mov ax, 0x4c00  ; EXIT_SUCCESS == 0.
        int 0x21
.fail:      mov ax,0x4c01  ; EXIT_FAILURE == 1.
        int 0x21

segment_code_end:

$AT:  ; .AddrType.
.OFFSET     equ 1
.SEGMENT    equ 2
.FARPTR     equ 3
.OFFSET16   equ 5

REL:  ; .RelType.
.IMPORDINAL equ 1
.IMPNAME    equ 2

segment_code_relocs:
.count:     dw (.end-.count-2)>>3  ; Each relocation is 8 bytes, 1 line each below.
        dw $AT.FARPTR | REL.IMPORDINAL<<8, ..@reloc0  -segment_code, (ModRefTab.user  -ModRefTab+2)>>1, 1     ; 'MESSAGEBOX'.'USER' @1.
        dw $AT.FARPTR | REL.IMPORDINAL<<8, ..@reloc1  -segment_code, (ModRefTab.kernel-ModRefTab+2)>>1, 0x5b  ; 'INITTASK'.'KERNEL' @91 == @0x5b.
        dw $AT.FARPTR | REL.IMPORDINAL<<8, ..@reloc2  -segment_code, (ModRefTab.kernel-ModRefTab+2)>>1, 0x1e  ; 'WAITEVENT'.'KERNEL' @30 == @0x1e.
        dw $AT.FARPTR | REL.IMPORDINAL<<8, ..@reloc3  -segment_code, (ModRefTab.user  -ModRefTab+2)>>1, 5     ; 'INITAPP'.'USER' @5.
.end:

; __END__

Answer 1

I don’t think this is supposed to be possible at all.

One reason why is that Windows may decide to run your program in protected mode. Your program obviously needs to have one executable segment to keep your code, and one writeable segment for the stack, which must be referred to in the field named .InitSsSegNo in the question (zero is only allowed for DLLs). And in protected mode, a segment selector can be executable or writeable, but not both. You simply cannot have CS=DS=SS in protected mode.

Okay, fine, in principle you can have more than one selector pointing to the same memory, with different access rights; the CPU alone will not stop you. But the Win16 programming model and the New Executable format do not provide for such a situation. Each segment must be declared as either code or data, and code segments may be entirely evicted from memory, to be later reloaded from the original executable file; there were no swap files to keep any modifications.⁰ For this to work well, the executable must contain fresh data, which is to say, the code segment cannot have been written into. And this is just as true in real-mode Windows as it is in protected mode.

That’s not to say you can’t save a couple of bytes in your tiny executable as it is. You can move the string constants into the code segment, then declare the data segment as not stored within the executable (essentially, make it a BSS segment) by setting the fofs and size fields of the segment table entry to zero. This saves 13 bytes. Other than that, though, I’m not seeing much way to save space without cutting too many corners.

---

⁰ See The Old New Thing posts: on GlobalLock and on segment tuning. I must admit I have a hard time finding a resource more authoritative and in-depth, so perhaps I am missing some obscure detail here that could make it work. Still, that was the general case at least.