-1

I am trying to read this line it is in the c code of legacy dll visual studio project , But I can't understand it

_fmemcpy((LPSTR FAR *)Defdat,(LPSTR FAR *)&DLLdat,sizeof(DATSETTING));

I am compiling for windows 64 bit visual studio 2010
libraries 

#include <stdio.h>
#include <string.h>
#include <windows.h>
#include <time.h>

Thanks

Lundin
  • 195,001
  • 40
  • 254
  • 396
XYZ
  • 164
  • 1
  • 1
  • 13
  • http://www.keil.com/support/man/docs/c166/c166_fmemcpy.htm ? – Simon Kraemer Sep 16 '15 at 13:38
  • 1
    How about some more informations? Libraries, compiler, architecture, ... – Simon Kraemer Sep 16 '15 at 13:39
  • 2
    What don't you understand about it? It is a memcpy specifying a pointer type that has been obsolete (at least in X86) since MANY versions of Windows ago. In headers after that pointer type became obsolete, the specification of that pointer type is supressed and you just have an ordinary memcpy with ordinary pointers. – JSF Sep 16 '15 at 13:39
  • Thanks all I will read about memcpy and obsolete with the explanation by JSF I hope I will manage it – XYZ Sep 16 '15 at 13:42
  • I am compiling for windows 64 bit visual studio 2010 @SimonKraemer – XYZ Sep 16 '15 at 13:44
  • @SimonKraemer I add the libraries – XYZ Sep 16 '15 at 13:46
  • 3
    This should be equivalent to `memcpy(Defdat, &DLLdat, sizeof(DATSETTING));`. – Jabberwocky Sep 16 '15 at 13:47
  • Far pointers were important with 16-bit Windows and Visual C++ 1.5 – Bo Persson Sep 16 '15 at 14:03
  • is this the far for the assembly code to know it is a far jump not a near jump :O – XYZ Sep 16 '15 at 14:05
  • @XYZ - No, not really. 16-bit Windows had segmented memory, and far pointers worked between segments. A near pointer was relative to one specific segment. – Bo Persson Sep 16 '15 at 15:31

1 Answers1

1

Back in the days of 16-bit windows, pointers could either be 16-bit pointers inside a data segment, or they could store both the 16-bit segment selector and a 16-bit address within that segment. The term for the latter kind of pointer was FAR, and any kind of pointer passed between different modules, such as the main program and the OS or a DLL, had to use them. So did all but the smallest real-world programs, which if nothing else used different segments for the heap and the stack. LPSTR is Hungarian notation for long pointer to string, so I think this programmer was being redundant.

There used to be separate versions of some library functions for FAR pointers, and that was the version of memcpy() that copied data between different segments on 16-bit Windows. To help port code over, it became a macro on 32-bit Windows that expands to memcpy(), and LPSTR expands to char *. FAR is just ignored.

Davislor
  • 14,674
  • 2
  • 34
  • 49