Compile error 64-bit system (1 Viewer)

Watched the Richard Rost video recommended by jdraw and had it sorted fairly quickly. Thanks to all for their input :love:
 
Last edited:
You'd think by this time they would have gotten better at this. We went from 8 to 16 to 32 to 64. Each upgrade has caused problems. I think Windows came in at 16 but that was a long time ago. I think all we are talking about is the size of internal registers and variables. How hard can it be to upgrade libraries with well tested code?

Size AND NATURE of internal registers, Pat. On the Intel boxes that became part of the PC, initially they didn't have memory management because the 16-bit bus could only handle 64 KB of physical memory anyway. The PC has gone through several memory models based more on internal memory bus size than anything else, though of course the processor chips ALSO grew. But we are lucky in a way. The FIRST Intel chip that could be programmed for device sequencers (think: automated laundry units) was the 4004, that was - you guessed it - based on a 4-bit "nibble." (A nibble is, of course, smaller than a byte.) Upgrading libraries in the days of the 16-bit machines was radically different than when you had 32 bits to play with. The problem is ALWAYS that program demand for space increases faster than the the space that can be supplied. With 64-bit addressing in the hardware, though, a LOT of neat tricks are available. The only catch? The modules were written to take advantage of the tricks of 32-bit space in order to make things fit, so programs had to be written cleverly and with an eye towards not wasting any space.

For example, if you write a MAIN program, your code will start above 1 MB because the first MB of memory is reserved for memory management structures. The Access 2 GB limit stems from having MSACCESS.EXE in the low half of memory along with the DLL files - libraries - and the program heap and stack structures. The tables and other database objects are in the high half of memory. But remember, that is half of a 32-bit addressing space, which turns out to be ... 2 GB.
 
For an expert, I would have thought it would be relatively easy to copy the lines, comment them out and amend for 64bit?
It is only the API calls after all, is it not?

I am on 2007, so no big deal for me. :)
Again, if you want Microsoft to start modifying your code for you, you're braver than I am.
 
Again, if you want Microsoft to start modifying your code for you, you're braver than I am.
I should add that I'm not referring to the technical ability to do it, but rather to the practice of having any outside actor unilaterally take responsibility for re-factoring your code according to that actor's opinion of what the code should have been. Rewriting APIs seems like a special case of a more general practice.
 
don't have to support any users still on 32 bit, then converting now is fine.
Once the changes for 64bit compatibility are tackled, it usually requires only minimal additional effort to stay compatible to 32bit. So, this is no real reason to not convert to 64bit.
 
We are not talking about changes to the OS, we are not talking about changes to compiled code, we are talking about changes to the declaration of variables in source code. What other code in the program would have to change? Why is changing the library code harder than changing a variable you defined in your app from single to double? You might have a bunch of places to change the size if you have defined work areas but there are no logic changes.

Granted, a lot of .DLL files internally use relative addressing modes, which ARE supported on an INTEL chip that has a PC register and which operate perfectly well even when the offsets are 16-bit or 32-bit. I think it may be my cautious nature (along the lines of "once burned, twice shy") that make me hesitant to suggest that the conversion is easy.
 

Users who are viewing this thread

Back
Top Bottom