Dllcall from 32 bit compile not working on 64 bit

[Jardz]

Thanks UEZ!

I've tested with your two exe's and I get the same results as I do with mine.

I've tested on 2x Win 8.1 x64s and a Win 7 SP1 Pro x64. All give the same result.

Just to confirm the problem, on a 64 bit OS with both exes the struct will be displayed, but only the 64bit will populate the elements with the default printer's settings.

So there will be no printer name in the first element when the x86 is run on a x64 OS.

What can be different with your OS?

[JohnOne]

Some sort of registry redirection going on / not working / acting weird maybe.

EDIT:

Just thinking in fonts.

Edited March 27, 2015 by JohnOne

[UEZ]

I must say sorry that I didn't understand your issue properly! 

I got the same result that the x86 is displayed but the values are 0 or empty whereas the x64 seems to work!

 

SORRY!

[Jardz]

No problem at all UEZ! I thought I going mad   I appreciate your help.

I still think the issue is with the pointer data type for the buffer in the dllcall, or one of data types in the buffer??

The function is failing to write to the struct, so must be one of those....

It Friday, may be the answer will come with the help of alcohol....

p.s. always drink responsibly!

[UEZ]

I assume that the $tagDEVMODE struct is not working for x86.
 

expandcollapse popup

typedef struct _devicemode {
  TCHAR dmDeviceName[CCHDEVICENAME];
  WORD  dmSpecVersion;
  WORD  dmDriverVersion;
  WORD  dmSize;
  WORD  dmDriverExtra;
  DWORD dmFields;
  union {
    struct {
      short dmOrientation;
      short dmPaperSize;
      short dmPaperLength;
      short dmPaperWidth;
      short dmScale;
      short dmCopies;
      short dmDefaultSource;
      short dmPrintQuality;
    };
    struct {
      POINTL dmPosition;
      DWORD  dmDisplayOrientation;
      DWORD  dmDisplayFixedOutput;
    };
  };
  short dmColor;
  short dmDuplex;
  short dmYResolution;
  short dmTTOption;
  short dmCollate;
  TCHAR dmFormName[CCHFORMNAME];
  WORD  dmLogPixels;
  DWORD dmBitsPerPel;
  DWORD dmPelsWidth;
  DWORD dmPelsHeight;
  union {
    DWORD dmDisplayFlags;
    DWORD dmNup;
  };
  DWORD dmDisplayFrequency;
#if (WINVER >= 0x0400)
  DWORD dmICMMethod;
  DWORD dmICMIntent;
  DWORD dmMediaType;
  DWORD dmDitherType;
  DWORD dmReserved1;
  DWORD dmReserved2;
#if (WINVER >= 0x0500) || (_WIN32_WINNT >= 0x0400)
  DWORD dmPanningWidth;
  DWORD dmPanningHeight;
#endif 
#endif 
} DEVMODE, *PDEVMODE, *LPDEVMODE;

I'm a C++ noob and I don't know how the Union can be implemented with AutoIt.

Edited March 27, 2015 by UEZ

[JohnOne]

You should look at '?do=embed' frameborder='0' data-embedContent>>

post #8 in particular.

[Jardz]

Hi all,

I've made progress on this, and as per the norm, I was very much off track! SORRY!!

When I started looking at this I was following the example here:

http://support.microsoft.com/en-us/kb/167345

I managed to get this working but decided to changed $DM_OUT_BUFFER to $DM_DEFAULT (same as $DM_OUT_DEFAULT)

The reason for this; I always wanted to start with the printer default settings, knowing they'd be more consistent.

This change worked well while I was writing and testing the script, so I forgot I made it...

Well, it seems it's this change that's preventing the x86 exe from working on x64 OS???

I can only speculate that the problem was not populating the buffer like I thought, but in fact not being able to get the default settings in the first place.

Possibly a bug or permissions issue??

Now I've gone back to $DM_OUT_BUFFER to get the settings it's all working again. So in short, the fix was changing a '1' to a '2'!

Many thanks to all who helped with this.