Gpc

gpc@gnu.de

5400 discussions

Re: Pointer & GPC question...
by Frank Heckenbach 22 Aug '97

22 Aug '97

Orlando Llanes wrote: > Cool :) Do I have to write a driver or something? Or will libs suffice? Or > do I even need to worry about the user not being root? suid refers to the > program? Like Ring 1/2/3 in PMode on Intel for example? > > From: Peter Gerwinski <peter(a)agnes.dida.physik.NO-SPAM-PLEASE.de> > > Well ... you can use the `/dev/mem' device to directly access memory, > > ... > > but then the program needs to be "suid root" to be executed. > > (In fact this is how `svgalib' accesses video memory.) It means a bit more. Root (and only root, AFAIK) can directly access all memory and ports, but root also has unlimited access to everything: all files (i.e. can read/modify/delete any private files of any user), all processes (i.e. can kill any user's processes), all devices (i.e. can format harddisks and all these things). So if I were the administrator of a multi-user system, I wouldn't install any unknown setuid root program -- that's the disadvantage. I guess it's not taken too seriously (and therefore not done much about it) by the Linux developers, because today, most Linux systems are single-user machines, AFAIK... (BTW: suid only means that the program runs under the ID and with the privileges of a certain user (usually, a program has the ID of the user who started it). So, a suid guest program would get all the privileges of the guest account, which probably isn't very much. Almost the only interesting thing is suid root...) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Pointer & GPC question...
by Orlando Llanes 22 Aug '97

22 Aug '97

Cool :) Do I have to write a driver or something? Or will libs suffice? Or do I even need to worry about the user not being root? suid refers to the program? Like Ring 1/2/3 in PMode on Intel for example? > From: Peter Gerwinski <peter(a)agnes.dida.physik.NO-SPAM-PLEASE.de> > Well ... you can use the `/dev/mem' device to directly access memory, > ... > but then the program needs to be "suid root" to be executed. > (In fact this is how `svgalib' accesses video memory.) Cool, that's the way I want it :) > That's what the LGPL stands for, *and* it allowes to link the library > with non-free software. The ordinary GPL would stand for the same, too, Noted :) > It's a good example how to use existing GCC libraries from GPC. See ya! Orlando Llanes

1 0

Re: Pointer & GPC question...
by Peter Gerwinski 22 Aug '97

22 Aug '97

According to Orlando Llanes: > According to myself (Peter Gerwinski): > > No way. > Bummer :( Well ... you can use the `/dev/mem' device to directly access memory, (* Linux lo-level file system access (here: memory access) *) Function mmap ( addr: Pointer; len: Word; prot, flags, fd, off: Integer ): Word; C; (* In fact it returns a pointer. But we convert it to Word. *) Function open ( filename: CString; Flags: Integer; ... ): Integer; C; Procedure InitTools; Var Dummy: Word; Function Allocate ( address, length: Word ): Pointer; Var segMem: Pointer; result: Word; begin (* Allocate *) segMem:= GetMem ( length + $FFF ); if Word ( segMem ) and $FFF <> 0 then inc ( Word ( segMem ), $1000 - Word ( segMem ) and $FFF ); if segMem = Nil then FatalError ( 'Linux drivers: cannot allocate video memory' ); result:= mmap ( segMem, length, $03, $11, MemoryHandle, address ); if Integer ( result ) <= 0 then FatalError ( 'Linux drivers: cannot mmap video memory' ); Allocate:= Pointer ( result ); end (* Allocate *); ... MemA0000:= Allocate ( $A0000, $10000 ); but then the program needs to be "suid root" to be executed. (In fact this is how `svgalib' accesses video memory.) > I plan to put it in the license where it's Copyrighted Freeware :) > Hopefully it's what the LGPL stands for. I will release the source code, > but I do want to retain the copyright, I won't charge for it's use tho. ^^(corrected) That's what the LGPL stands for, *and* it allowes to link the library with non-free software. The ordinary GPL would stand for the same, too, but would only allow to link the library with other free software. > I saw it, but nothing about memory access, It's a good example how to use existing GCC libraries from GPC. > besides, I don't see why > Borland's BGI should live on. For compatibility's sake. Nothing else. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Can't run gpc_970714 :-(
by Ken Linder 22 Aug '97

22 Aug '97

Hi All I am not too sure if I am experiencing brain damage or what... Since I downloaded the binary Linux GPC file gpc-970714_i586-linux.tar and unzipped it, I have not been able to compile ANY pascal code.:-( OS: Linux 2.0.27 GCC: 2.7.2.1 What I get when I try to compile and pascal source... /tmp/cca00363.i:1: numeric constant with no digits /tmp/cca00363.i:1: numeric constant with no digits /tmp/cca00363.i:1: invalid #line etc... etc... etc... This wouldn't be because I am using 486 hardware would it? Thanks for the assist! Ken L.

1 0

Re: Pointer & GPC question...
by Orlando Llanes 21 Aug '97

21 Aug '97

I plan on using them to fill gaps where OS specific stuff is concerned, File I/O, Network I/O, etc. > From: Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> > Use them with care! This way, you can only support some limited set of known > ... > use "sizeof(pointer)"... I know it doens't, but I don't like Borland's API. > (* BTW: BGI2GRX doesn't use Borland's inefficient BGI drivers and such, it > just provides the same (nearly) interface as Borland's Graph unit. *) See ya! Orlando Llanes

1 0

Re: Pointer & GPC question...
by Frank Heckenbach 20 Aug '97

20 Aug '97

Orlando Llanes wrote: > > (*$ifdef __MSDOS__ *) (* The definitions are case-sensitive *) > > ... > > (*$endif *) (*$endif *) (*$endif *) > Thanks :) Use them with care! This way, you can only support some limited set of known platforms, but the GNU compiler is ported to more and more platforms... Whenever you can, you might want to use portable way of doing things. E.g. to distinguish whether a pointer has 32 or 64 bits (or more), you can use "sizeof(pointer)"... > > For an example what I mean, look at Sven's excellent `BGI2GRX' Unit, > > also known as GPC's `Graph' Unit. > I saw it, but nothing about memory access, besides, I don't see why > Borland's BGI should live on. (* BTW: BGI2GRX doesn't use Borland's inefficient BGI drivers and such, it just provides the same (nearly) interface as Borland's Graph unit. *) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Correction...
by Orlando Llanes 19 Aug '97

19 Aug '97

Errr... I DO want to retain the Copyright. -- See ya! Orlando Llanes

1 0

Re: Pointer & GPC question...
by Orlando Llanes 19 Aug '97

19 Aug '97

Thanks :) > (*$ifdef __MSDOS__ *) (* The definitions are case-sensitive *) > ... > (*$endif *) (*$endif *) (*$endif *) Bummer :( > No way. Will do. > For DJGPP, see the GPC FAQ and the DJGPP FAQ. The "best" way for direct It is, but for starters I want to do it high level, I don't know much about PMode yet. In fact, I may not even have to code in low level ASM, reason I say this is because I saw a Mode-X lib (XLib for GCC I think), and upon examining the source, I didn't see a single ASM statement in it. > memory access IMHO is to use assembler. You can use the following function > to convert a segment address to a selector: Noted :) > Function SegToSel ( Seg: ShortWord ) Sel: Word; > ... > end (* SegToSel *); That's the problem, I heard SVGALib is a bit slow. Besides, I don't plan on going Linux just yet, once I have a strong base in PMode/DOS I'll work on the Linux port. I may use SVGALib for short term tho. > For Linux, better don't access memory directly. Instead, use (S)VGALIB or > some other well-documented interface to graphics mode. I plan to put it in the license where it's Copyrighted Freeware :) Hopefully it's what the LGPL stands for. I will release the source code, but I don't want to retain the copyright, I won't charge for it's use tho. > Sounds good. Do you consider to put it under the GNU Library General > Public License? Heard of it, saw the demo Caveman, and didn't like it much. The sound lib won't run under '95, I don't know exactly where the problem is, but I want the lib to run efficiently under a Full Screen Windows '95 DOS Box without being prompted to run in MS-DOS mode. I'll take a look at it tho, maybe it can tip me off on how to set the address of a pointer :) My ultimate goal is to provide an API so that it truly is recompile source on each platform and compiler rather than re-edit to recompile. > For DJGPP, there is a game library called `Allegro' for GNU C. > ... > good starting point for you to write such a Unit to use `Allegro' I saw it, but nothing about memory access, besides, I don't see why Borland's BGI should live on. I plan to make my libs work in VGA, VESA, VBE2, and certain Mode-X configurations. > For an example what I mean, look at Sven's excellent `BGI2GRX' Unit, > also known as GPC's `Graph' Unit. See ya! Orlando Llanes

1 0

Re: Pointer & GPC question...
by Peter Gerwinski 18 Aug '97

18 Aug '97

According to Orlando Llanes: > > Do you have access to these machines for beta-testing? Yup. > That reminds me, are > there definitions for the environment GPC is compiling for? For example: > [...] Yes: (*$ifdef __MSDOS__ *) (* The definitions are case-sensitive *) ... (*$else *) (*$ifdef __osf__ *) (* One operating system for the Alpha *) ... (*$else *) (*$ifdef __linux__ *) (* Another operating system for *) (*$ifdef __i386__ *) (* the Alpha - or for the i386+ *) ... (*$else *) (*$ifdef __alpha__ *) ... (*$endif *) (*$endif *) (*$endif *) (*$endif *) > How do I set a pointer to point to the VGA (for example) in a way that can > be ported to at least Linux? No way. For DJGPP, see the GPC FAQ and the DJGPP FAQ. The "best" way for direct memory access IMHO is to use assembler. You can use the following function to convert a segment address to a selector: Function SegToSel ( Seg: ShortWord ) Sel: Word; begin (* SegToSel *) asm ( 'int $0x31' : '=a' ( Sel ) : 'a' ( 2 ), 'b' ( Seg ) : '%eax', '%ebx', '%ecx', '%edx', '%esi', '%edi', '%ebp' ); end (* SegToSel *); For Linux, better don't access memory directly. Instead, use (S)VGALIB or some other well-documented interface to graphics mode. > I'm going to start work again on my game lib > (graphics part), and M13h would be a start :) Another thing is how do I > modify the contents referenced by the pointer? Writing a byte so it's > portable, writing a word so it's portable, etc. My ultimate goal is to port > this lib to PMode DOS, Mac, '95, Linux, X, and whatever other platform I > can get my grubby hands on, but I'll settle for PMode DOS for now :) Sounds good. Do you consider to put it under the GNU Library General Public License? For DJGPP, there is a game library called `Allegro' for GNU C. To use it with GNU Pascal, you only need to translate the C header files to a Unit with empty implementation part. I think, `Allegro' is under the GNU LGPL, so it is available in source code. Maybe it's a good starting point for you to write such a Unit to use `Allegro' with GPC? For an example what I mean, look at Sven's excellent `BGI2GRX' Unit, also known as GPC's `Graph' Unit. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Testing...
by Orlando Llanes 18 Aug '97

18 Aug '97

Please don't flame me for this, I wrote to this mailing list, and it somehow ended up in the wrong e-mail address. See ya! Orlando Llanes

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc