It's not hard to get the address of data in 32-bit addressing. You just interleave the data inside your assembly, something like the following (pseudo code I haven't done this in a while):
...
call continue
.db "Hello World!\n\0"
continue:
pop eax
...
Since 'call' just turns into a 'push eip; jmp target' (simplified, sorry), the address of the string is now pushed onto the stack. Popping off the top, now eax contains the address of the string "Hello World!\n\0". Since in 32-bit ABI most parameters are passed on the stack, many times you don't even need to 'pop' the address off the stack, it'll just be part of your arguments to the function.
Old school malware used this a lot to 1) run regardless of the memory base address it was loaded at and 2) confuse some disassemblers (you can use silly conditionals that are always true or false to control whether you execute the 'call' instruction or not, forcing the disassembler to try and 'disassemble' the string into valid x86 opcodes)
I'm guessing this is referring to the fact that early versions of Fortran stored return addresses in specific memory locations (at the end of the function definition IIRC) instead of on a call stack. This is why those versions of Fortran couldn't do recursion, because the new return address would overwrite the old one.
It seems weird now, but natural at time. Point a register at the data following the call, rely on the caller advancing over the argument and jumping back to the (presumed) code after the data. The stack isn't involved at all...
Old school malware used this a lot to 1) run regardless of the memory base address it was loaded at and 2) confuse some disassemblers (you can use silly conditionals that are always true or false to control whether you execute the 'call' instruction or not, forcing the disassembler to try and 'disassemble' the string into valid x86 opcodes)