Converting 32 bit code to 64 bit code

[John Z]

Here is a nice summary about things to consider and do to convert 32 bit into 64 bit code.
It is from Oracle, June 2016 - yes I know I'm way behind 

John Z

[Vortex]

Hi John,

Thanks. Here is another link :

http://www.codeproject.com/Articles/17263/Moving-to-Windows-Vista-x64

[John Z]

When upgrading another program to 64 bit I ran into this -
strlen() in 32 bit returns size_t which seems to be DWORD
strlen() in 64 bit returns size_t which seems to be unsigned long long int

so far so good - however in fileapi.h the WriteFile function
WINBASEAPI BOOL WINAPI WriteFile(HANDLE, LPCVOID, DWORD, LPDWORD, LPOVERLAPPED);
doesn't change parm 3 so when compiling for 64 bits you get
Log_To_File.c(101): warning #2215: Conversion from 'unsigned long long int' to 'unsigned long int'; possible loss of data or unexpected result.

The only way I can see is either suppress the #2215 warning or cast (DWORD)strlen()

Doesn't seem to be a WriteFile64 .... and WriteFile is not marked as depreciated..

Thoughts?

John Z

So far upgrading from my old 32 bit programs to 64 bit has been relatively simple.  Benefit is questionable other than future proofing against 32 bit support disappearing.

[WiiLF23]

"If your application needs to handle large files and you want to work with 64-bit sizes, you might consider using the WriteFileEx function, which has a different signature that includes a LARGE_INTEGER parameter for the file offset. This function is designed to work with large files on 64-bit systems."

Code: [Select]

WINBASEAPI BOOL WINAPI WriteFileEx(
    HANDLE hFile,
    LPCVOID lpBuffer,
    DWORD nNumberOfBytesToWrite,
    LPOVERLAPPED lpOverlapped,
    LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine
);


[John Z]

Thanks WiiLF23,

Appreciate the input - I did look at that and it seems overly complex for the simple log file entry.

There are other file methods of course, and it is just a warning, but to me it points out that 64 bit seems to not be fully implemented across the winbaseapi by Microsoft.

John Z

[frankie]

When upgrading another program to 64 bit I ran into this -
strlen() in 32 bit returns size_t which seems to be DWORD

Yes because a DWORD can cover a string long the whole addressing space 32bits => 4Gb.

strlen() in 64 bit returns size_t which seems to be unsigned long long int

Once again address whole memory 64bits => 16 exibytes (18'446'744'073'709'551'616 bytes)

so far so good - however in fileapi.h the WriteFile function
WINBASEAPI BOOL WINAPI WriteFile(HANDLE, LPCVOID, DWORD, LPDWORD, LPOVERLAPPED);
doesn't change parm 3 so when compiling for 64 bits you get
Log_To_File.c(101): warning #2215: Conversion from 'unsigned long long int' to 'unsigned long int'; possible loss of data or unexpected result.

Yes there could be a loss of data if your record is bigger than 4Gb. Indeed you need to write so much data?

The only way I can see is either suppress the #2215 warning or cast (DWORD)strlen()

The cast doesn't harm in 32 or 64bits. Unless you have to write more than 4Gb in one write...

Doesn't seem to be a WriteFile64 .... and WriteFile is not marked as depreciated..
Thoughts?

Probably if you need to transfer such big amount of data, an operation that will take time anyway despite how fast is your disk, you'll not use this simple technique. So don't seems to be a really need for WriteFile64...
To keep contained buffers extensions and manage the update of transfer data more appropriately you'll use an asynchronous transfer, overlapped, to keep running code and updating transfer buffers on the fly.

Do you really need to transfer more than 4Gb at once?   

[John Z]

In the spirit in which the thoughts were given, I thank you frankie! 

No, of course not, I do not have even a minuscule fraction of 4Gb to deal with.

John Z