[C++] type far??

[Verwijderd]

code:

char far *Ptr;
//...
Ptr = (char far *)RxBuffer;
//...
Ptr = (char far *)TxBuffer;

mijn borland 5.5 compiler, en MS VC++ 6.0 geven hierbij een foutmelding, dat het type far niet bestaat:

code:

Declaration syntax error in function main
Undefined symbol 'Ptr' in function main

deze foutmeldingen geeft Borland...

VC++ 6 zegt dit:

code:

error C4226: nonstandard extension used : 'far' is an obsolete keyword

Welk type wordt wel bedoelt??

[elnino]

Op vrijdag 21 december 2001 12:30 schreef K-Mile het volgende:

code:

char far *Ptr;
//...
Ptr = (char far *)RxBuffer;
//...
Ptr = (char far *)TxBuffer;

char far * is dubbel, moet of "far *" zijn of "char *", tenminste dat dacht ik, maar C++ is een flexibele taal, dus misschien is er meer mogelijk...

[ACM]

Wat is een "char far" ??

Dat is voor het eerst dat ik dat zie, waarschijnlijk mag je die "far" (zoals de obsolete melding ook al zegt) gewoon weglaten ?

[Verwijderd]

nee, als ik far weglaat doet het het niet...

ik heb wat gezocht, far zat in oude dos library's, oa in graph.h voor zover ik begrepen heb. maar MS heeft graph.h eruit gehaald om een of andere duistere reden, dus ik moet uit zien te zoeken wat ze ermee willen, dus welk type het moet/kan zijn, maar daar ben ik niet goed in C++ genoeg voor...

[Verwijderd]

wat moet die "far" doen dan wil 2x een char of 1x een char far *ptr als je 2 chars wil een "," de tussen..



/me denkt dat dit beetje overbodig is

[mvdejong]

"far" wordt/werd in sommige MicroSoft C-compilers gebruikt om in een programma dat verder alleen offset-adressering (dus zonder segment) kon gebruiken (maakte je programma's compacter en sneller), te vertellen dat voor een bepaald adres wel segment+offset moesten worden gebruikt, bijvoorbeeld omdat je in het fysieke geheugen wilde te rommelen.

Je had toen verschillende geheugen-"modellen" (een segment is maximaal 64 kByte) :
SMALL 1 code-segment en 1 data-segment;
MEDIUM 1 code-segment en meerdere data-segmenten;
LARGE meerdere code-segmenten en meerdere data-segmenten;
HUGE net zoals large, maar met de mogelijkheid voor data-structuren (zoals arrays) > 64 kByte (dus meerdere segmenten overspannend).

"far" gewoon weglaten, het is niet relevant als de compiler het niet snapt, meestal wordt tegenwoordig in een 32-bits geheugen-model gewerkt, waar het segment/data-onderscheid niet meer bestaat.

[Verwijderd]

nop, 'far' weglaten => 15 errors erbij...

naja, ik snap niet dat het ZO moeilijk is om een progje te vinden/maken wat gewoon via seriele poort naar een andere pc zijn seriele poort een string stuurt oid..

damn...

ik heb echt 7 voorbeeld sources gedownload, zowel in c(++) als qbasic, en ze geven allemaal errors bij het compilen

[mvdejong]

Dan moet je gaan zoeken naar een equivalent.

Zo te zien aan je code zijn die 2 buffers inderdaad adressen buiten je eigenlijke programma, en moeten dus met een volledig adres worden aangesproken.

Wat zijn de foutmeldingen die je zonder "far" krijgt ?

[drm]

Op vrijdag 21 december 2001 13:32 schreef K-Mile het volgende:
nop, 'far' weglaten => 15 errors erbij...

naja, ik snap niet dat het ZO moeilijk is om een progje te vinden/maken wat gewoon via seriele poort naar een andere pc zijn seriele poort een string stuurt oid..

damn...

ik heb echt 7 voorbeeld sources gedownload, zowel in c(++) als qbasic, en ze geven allemaal errors bij het compilen

Waarom gebruik je dan niet een oudere compiler?

Borland C++ 3.x gaat het wel goed in, waarschijnlijk. Dat is een prima DOS compiler, en far heb ik daar ook heel vaak in gezien

_edit:
btw. het gaat niet om een char far maar om far pointer, oftewel far *.

Maar ik geloof dat daar al e.e.a. over uitgelegd stond?
^{sorry, ben lui vandaag}

[mvdejong]

Op vrijdag 21 december 2001 13:40 schreef drm het volgende:

[..]

Waarom gebruik je dan niet een oudere compiler?

Borland C++ 3.x gaat het wel goed in, waarschijnlijk. Dat is een prima DOS compiler, en far heb ik daar ook heel vaak in gezien

_edit:
btw. het gaat niet om een char far maar om far pointer, oftewel far *.

Maar ik geloof dat daar al e.e.a. over uitgelegd stond?
^{sorry, ben lui vandaag}

Een "far *" is een in sommige compilers toegestane notatie voor een "type-loze" pointer (van het "lange-afstands" soort), dus waar niet voor gespecificeerd is naar welk data-type er wordt verwezen. Dit gaat alleen fout bij sommige architecturen waar pointers naar verschillende data-typen niet zomaar uitwisselbaar zijn.

[drm]

Op vrijdag 21 december 2001 13:47 schreef mvdejong het volgende:

[..]

Een "far *" is een in sommige compilers toegestane notatie voor een "type-loze" pointer (van het "lange-afstands" soort), dus waar niet voor gespecificeerd is naar welk data-type er wordt verwezen. Dit gaat alleen fout bij sommige architecturen waar pointers naar verschillende data-typen niet zomaar uitwisselbaar zijn.

Hmm, ja ik bedoelde alleen maar te zeggen dat bv:

code:

char far *ptr;

ptr hier niet een pointer is naar een type "char far" maar een far pointer is naar een type "char"

[Verwijderd]

ok, voor die liefhebbers:

de code:

code:

/*  simple.c (01/22/99)
**
**  Must be executed from DOS command line (boot to DOS in Win95).
*/

#include <stdio.h>
#include <stdlib.h>
#include <dos.h>
#include <string.h>
#include <conio.h>

#include "pcl4c.h"

#define FALSE 0
#define TRUE !FALSE

/*** Global Variables ***/

int Port = COM1;        /* Port COM1 */
int BaudCode;        /* baud rate code ( index into BaudRate[] ) */
char *BaudRate[10] =  {"0","300","1200","2400","4800","9600",
                 "19200","38400","57600","115200"};
char *UartString[4] = {"8250/16450", "16550", "16650", "16750"};
char RxBuffer[1024+16];
char TxBuffer[512+16];

/*** local prototypes */

int BaudMatch(char *);
int ErrorCheck(int);

/*** main ***/

void main(int argc, char *argv[])
{char c;
 int  i, rc;
 char *Ptr;
 int  Seg;
 int  Version;
 if(argc!=3)
   {printf("Usage: SIMPLE <port> <baud>\n");
    exit(1);
   }
 /* get port number from command line */
 Port = atoi(argv[1]) - 1;
 if((Port<COM1) || (Port>COM20))
     {printf("Port must be COM1 to COM20\n");
    exit(1);
     }
 /* get baud rate from command line */
 BaudCode = BaudMatch(argv[2]);
 if(BaudCode<0)
     {printf("Cannot recognize baud rate = %s\n",argv[2]);
    exit(1);
     }
 /* display PCL4C version */
 Version = SioInfo('V');
 printf("PCL4C Version %d.%d\n",Version>>4,0x0f&Version);
 /* setup 1024 byte receive buffer */
 Ptr = (char *)RxBuffer;
 Seg = FP_SEG(Ptr) + ((FP_OFF(Ptr)+15)>>4);
 ErrorCheck( SioRxBuf(Port,Seg,Size1024) );
 /* setup 512 byte transmit buffer */
 Ptr = (char *)TxBuffer;
 Seg = FP_SEG(Ptr) + ((FP_OFF(Ptr)+15)>>4);
 ErrorCheck( SioTxBuf(Port,Seg,Size512) );
 /* set port parmameters */
 ErrorCheck( SioParms(Port,NoParity,OneStopBit,WordLength8) );
 /* reset the port */
 ErrorCheck( SioReset(Port,BaudCode) );
 /* set DTR and RTS */
 ErrorCheck( SioDTR(Port,'S') );
 ErrorCheck( SioRTS(Port,'S') );

#if 0
 /* set RTS/CTS flow control. */
 ErrorCheck( SioFlow(Port,18) );
 puts("Flow control on");
#endif

 /* Set FIFO level */
 i = SioFIFO(Port,LEVEL_4TH);
 printf("[%s]\n",UartString[i]);

 printf("\nEnter terminal loop ( Type ^Z to exit )\n");
 /* enter terminal loop */
 while(TRUE)
     {if(SioBrkKey())
      {/* restore COM port status & exit */
       printf("BREAK\n");
       SioDone(Port);
       exit(2);
      }
    /* was key pressed ? */
    if(kbhit())
        {i = getch();
         if((char)i==0x1a)
          {/* restore COM port status & exit */
           SioDone(Port);
           exit(1);
          }
         else
          {
           SioPutc(Port,(char)i);
          }
        } /* end if */
    /* any incoming over serial port ? */
    i = SioGetc(Port,0);
    if(i>-1) putch((char)i);
     } /* end while */
} /* end main */

int ErrorCheck(int Code)
{/* trap PCL error codes */
 if(Code<0)
     {printf("ERROR %d:",Code);
    SioError(Code);
    SioDone(Port);
    exit(1);
     }
 return(0);
} /* end ErrorCheck */


int BaudMatch(char *P)
{int i;
 /* find baud rate in table */
 for(i=0;i<10;i++) if(strcmp(BaudRate[i],P)==0) return(i);
 return(-1);
}

de foutmeldingen MET far:

code:

Error E2141 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 37: Declaration syntax error in function main
Error E2451 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 60: Undefined symbol 'Ptr' in function main
Error E2293 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 60: ) expected in function main
Warning W8065 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 61: Call to function 'FP_SEG' with no prototype in function main
Warning W8065 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 61: Call to function 'FP_OFF' with no prototype in function main
Error E2293 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 64: ) expected in function main
Warning W8065 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 65: Call to function 'FP_SEG' with no prototype in function main
Warning W8065 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 65: Call to function 'FP_OFF' with no prototype in function main

ZONDER far

code:

Warning W8065 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 61: Call to function 'FP_SEG' with no prototype in function main
Warning W8065 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 61: Call to function 'FP_OFF' with no prototype in function main
Warning W8065 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 65: Call to function 'FP_SEG' with no prototype in function main
Warning W8065 C:\DOCUME~1\ADMINI~1\MYDOCU~1\C__ZOO~1\pcl4c621\SIMPLE.C 65: Call to function 'FP_OFF' with no prototype in function main
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_SioInfo' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioRxBuf' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_FP_SEG' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_FP_OFF' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioTxBuf' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioParms' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioReset' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioDTR' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioRTS' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioFIFO' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioBrkKey' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioPutc' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioGetc' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioError' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ
Error: Unresolved external '_SioDone' referenced from C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\MY DOCUMENTS\C++ ZOOI\PCL4C621\SIMPLE.OBJ

zo dit is mijn probleem

[.oisyn]

dit gaat sowieso niet werken op een 32 bits platform omdat je hier met segment/offset pairs werkt (dat is ook precies wat een FAR-pointer is: niet alleen een offset maar een segment/offset)

En aangezien je in 32 bits mode in principe de hele 4GB addressering tot je beschikking hebt zijn FAR pointers obsolete

bovendien heb je niet ineens meer errors, alle compiler-errors zijn weg, dus krijg je link-errors (het volgende stapje dus ). Die kreeg je ook wel als je FAR erbij laat staan, maar omdat je dan compiler-errors krijgt komt ie niet eens aan het linken toe

[mvdejong]

Kijk, daar hebben we wat aan !

Allereerst, met het weglaten van "far" gaat het aantal compilatie-fouten omlaag, er blijven alleen maar waarschuwingen over. Daardoor wordt de link-slag wel opgestart (met "far" gaat de compilatie zo fout dat de compiler weigert de link-slag op te starten). De rest van de fouten zijn link-fouten.

En daar heb je een volgend probleem. De source waar je mee bezig bent vereist een library voor het aansturen van seriele poorten (al die "_Sio*"-functies), en die heb je niet, of in ieder geval niet gedefinieerd als benodigd.

De FP_OFF- en FP_SEG-functies zijn geen echte functies, maar macro's die een 32-bits adres opsplitsen in het segment-gedeelte en het offset-gedeelte.

Je zult dus eerst een SIO-library te pakken moeten zien te krijgen, maar ik twijfel ten zeerste of de oorspronkelijke versie waarmee deze code samenwerkt nog werkt met de compilers die je nu gebruikt. Als je een ander library te pakken krijgt, zul je de functies moeten ombouwen, met name wat er gebeurt in de Sio?xBuf-functies is zeer segment/offset-gerelateerd.

Ik sluit me dus ook aan bij OiSyN in de conclusie dat dit niet gaat werken onder een moderne 32-bits compiler.

Dus waar je naar moet zoeken :
- de SIO-library die bij die source hoort;
- een C-compiler die uit ongeveer dezelfde periode stamt, zodat je de juiste geheugen-modellen kunt gebruiken.
Het resulterende programma zal dus ook altijd in een DOS-box draaien.

Een adres in de oude kreupele DOS-adressering wordt (uit pure technisch-historische redenen die te maken hebben met de oorspronkelijke 16-bits-architectuur van de 80x86-processor-reeks) opgebouwd uit een 16-bits segment- en een 16-bits offset-adres. Het segment is 4 bits naar rechts verschoven t.o.v. een offset, ze overlappen elkaar dus aanzienlijk.

code:

SSSSSSSSSSSSSSSS....
....OOOOOOOOOOOOOOOO

Het echte adres is de optelling van deze 2 adressen.
Die 16 overlappende bits kun je dus op elke gewenste manier verdelen, er zijn vele manieren om hetzelfde adres weer te geven, en je kunt dus altijd "normaliseren" naar een segment-/offset-combinatie dat alleen de laatste 4 bits van de offset 0 zijn :

code:

SSSSSSSSSSSSSSSS....
................OOOO

Aan de Sio?xBuf-functies wordt alleen maar een segment doorgegeven, maar de adressen van de gereserveerde buffers bestaan uit het segment-adres van het data-segment, plus een offset t.o.v. het begin van data data-segment. Daarom worden die adressen "genormaliseerd", want je kunt een adres opgebouwd uit een segment+offset altijd omrekenen naar een adres waarbij de offset 0 is, als je een marge van 4 bits (=16 bytes) accepteert.
Vandaar dat er dus 15 bij het adres van Ptr wordt opgeteld, en vervolgens een right-shift van 4 volgt. Je verliest nu mogelijk wat bytes aan het begin van de buffer, en dat verklaart de "+16" in de definitie van beide buffers.

[drm]

mvdejong schreef een hele duidelijke en verhelderende verklaring

leuk

meer! meer!

[The End]

Zou de compiler het ook niet pakken (op de linking errors na) als je om de hele code: extern "C" { } zet?
Als ik problemen heb met oude C code in visual studio, dan doe ik dit...

[JayTaph]

Zoals ik uit de code kan opmaken gaat dit programma gebruik maken van de standaard int14 functies... Gaat dit wel werken in win98 DOS mode? (met andere woorden: draait win98 DOS wel realmode?)

(Sorry voor de mensen die dit niet snappen, tis meer een vraag voor mvdjong en consorten)

[.oisyn]

Op vrijdag 21 december 2001 22:05 schreef JayTaph het volgende:
Zoals ik uit de code kan opmaken gaat dit programma gebruik maken van de standaard int14 functies... Gaat dit wel werken in win98 DOS mode? (met andere woorden: draait win98 DOS wel realmode?)

(Sorry voor de mensen die dit niet snappen, tis meer een vraag voor mvdjong en consorten)

alle windows os'en draaien in een DOS-window virtual x86 mode. dat komt voor de programma's die in die mode werken overeen met realmode (segment/offset pairs, enz.), maar heeft voor het systeem de eigenschappen van protected mode (beschikt over interrupt gates naar 16 en 32 bits protected mode interrupt vectors, poortjes en cli + sli instructies zijn protected, paging, enz.)

[mvdejong]

Als dit programma wordt gecompileerd en gelinked met de juiste library en de compiler is oud genoeg om het inderdaad te doen, dan zal het inderdaad in een DOS-window gaan lopen, en dan zijn al die oude DOS-features wel beschikbaar, dus onder W'98 zijn er geen problemen te verwachten.

OS-en die gebaseerd zijn op de NT-kernel (NT, 2000, XP), hebben echter de neiging om hardware-toegang via vaste procedures toe te staan, en je zou wel eens probleem kunnen krijgen om aan een seriele poort te klooien met dit soort low-level functies.

[.oisyn]

volgens mij wrappen zowel windows 9x als 2000 en xp al die lowlevel interrupt vectors naar een lap code die het vervolgens op de windows manier doet (NT zelf is een ander verhaal)

[Verwijderd]

als ik dit op een ouwe turbo C compiler, die nog op DOS 5.0 draait, compile, dan zou het dus kunnen werken als ik die library te pakken krijg... maar, kan ik het progje dan wel gebruiken onder win2K, lijkt mij niet, als ik jullie reacties zo lees..

ok, dan moet ik dezelfde code nog een keer zoeken voor Win32, zodat ik beide programma's kan draaien om de communicatie tot stand te brengen. (het is nl van Win2K bak naar ouwe toshiba T1800 laptop, ong 6 a 8 jaar oud denk ik..) dus ik zou 2 progjes moeten zoeken??

[.oisyn]

ik denk eerlijk gezegd dat het wel werkt onder win2k, maar dat weet ik dus niet zeker

[JayTaph]

Op zaterdag 22 december 2001 00:30 schreef OiSyN het volgende:

[..]

alle windows os'en draaien in een DOS-window virtual x86 mode.

Ja, of v86 mode was ik nog vergeten te melden.