Download Pelles C here: http://www.pellesc.se
include OpenNewTxtForOutput.inc
.data
msg db 'This is a test.',0
msg2 db 'Another test',0
file db 'Test.txt',0
.data?
hFile dd ?
.code
OpenNewTxtForOut PROC filename:DWORD
LOCAL mode:DWORD
mov mode,'w'
invoke fopen,filename,\
ADDR mode
ret
OpenNewTxtForOut ENDP
put PROC handle:DWORD,pMemory:DWORD
invoke lstrlen,pMemory
invoke fwrite,pMemory,1,\
eax,handle
ret
put ENDP
close PROC handle:DWORD
invoke fclose,handle
ret
close ENDP
start:
invoke OpenNewTxtForOut,ADDR file
mov hFile,eax
invoke put,eax,ADDR msg
invoke put,hFile,ADDR msg2
invoke close,hFile
invoke ExitProcess,0
END start
Quote from: John Z on March 28, 2026, 10:56:36 AMDownloaded n3220 working draft.Thanks for looking at this! Glad it's not just me, then...
Problem is not your English - it is the inconsistency in the proposed spec.
different authors I'm guessing.Quote from: PhilG57 on February 14, 2026, 05:58:31 PMIt would be helpful to me if the editor would show which #ifdef/#else/#endif paths were active. This might be done by highlighting, or not, the appropriate code sections. Sometime I run into multiple, nested #ifdef's and sorting it all out is a big pain. Thanks.I actually would want this too, and have invested some time investigating this in the past. The problem is that it's not trivial to do accurate and fast enough. Inaccurate is unhelpful, and waiting on the editor is useless.
Quote from: TimoVJL on March 27, 2026, 07:44:02 PMgcc is multitarget compiler and see things in that way.Yes, but these functions should operate on the loaded value, disregarding the memory byte-order.
memory layout can be different in little-endian / big-endian things ?
Page created in 0.040 seconds with 15 queries.