bloodshed 
Author Message
 bloodshed

greetings

i've recently downloaded {*filter*}shed dev gpc, dev_gnu_Pascal-1.9.2.exe
from http://www.{*filter*}shed.net

the ide (or the compiler??) can't compile and reports that it cannot
find the file gpcpp.exe at the path c:/..something../gpcpp.exe

the file exists and the path is correct, exept that the program is
referenceing the path with forward-slash (unix style), but the corect
path should be writen with back-slash (ms-dos style).
i think that's the only problem so far.

the ide starts and works fine, but cannot execute the source.

please send some help.

Vasko



Mon, 19 Dec 2005 19:58:19 GMT  
 bloodshed

Quote:

> greetings

> i've recently downloaded {*filter*}shed dev gpc, dev_gnu_pascal-1.9.2.exe
> from http://www.{*filter*}shed.net

> the ide (or the compiler??) can't compile and reports that it cannot
> find the file gpcpp.exe at the path c:/..something../gpcpp.exe

> the file exists and the path is correct, exept that the program is
> referenceing the path with forward-slash (unix style), but the corect
> path should be writen with back-slash (ms-dos style).
> i think that's the only problem so far.

Is that GPC cygwin or mingw based? If it is cygwin based try entering.

/cygdrive/c/something/gpcpp.exe

This is a confusing thing of cygwin (not gpc specific), and a reason to
avoid cygwin IMHO.



Tue, 20 Dec 2005 05:05:54 GMT  
 bloodshed

Thanks for replay Marco.

Quote:
> Is that GPC cygwin or mingw based?

It is mingw32 based. Here is the path apering in the 'Compiler and
linker output' window.
'c:/lang/dev_gpc/lib/gcc-lib/mingw32/2.95.3-6/gpcpp.exe'

The path should be: 'c:\lang\dev_gpc\lib\gcc-lib\mingw32\2.95.3-6\gpcpp.exe'.
I have tried searching the path with text search in all instaled
files, with no result. Seems, it is not in an .ini or .cfg file :(

Quote:
> If it is cygwin based try entering.

> /cygdrive/c/something/gpcpp.exe

> This is a confusing thing of cygwin (not gpc specific), and a reason to
> avoid cygwin IMHO.

Vasko

ps - setgpc.bat is a batch file to set up GPC GNU Pascal for Mingw. It
only has 3 lines. They all look fine to me, every directory is
separeted with backslash.



Tue, 20 Dec 2005 13:38:23 GMT  
 bloodshed

Quote:

> greetings

> i've recently downloaded {*filter*}shed dev gpc, dev_gnu_pascal-1.9.2.exe
> from http://www.{*filter*}shed.net

> the ide (or the compiler??) can't compile and reports that it cannot
> find the file gpcpp.exe at the path c:/..something../gpcpp.exe

> the file exists and the path is correct, exept that the program is
> referenceing the path with forward-slash (unix style), but the corect
> path should be writen with back-slash (ms-dos style).
> i think that's the only problem so far.

> the ide starts and works fine, but cannot execute the source.

> please send some help.

> Vasko

Are you using windows 9x?    There's a path problem whcih has a fix:

http://www.*-*-*.com/



Tue, 20 Dec 2005 16:01:42 GMT  
 bloodshed

Quote:


>> Is that GPC cygwin or mingw based?

> It is mingw32 based. Here is the path apering in the 'Compiler and
> linker output' window.
> 'c:/lang/dev_gpc/lib/gcc-lib/mingw32/2.95.3-6/gpcpp.exe'

> The path should be: 'c:\lang\dev_gpc\lib\gcc-lib\mingw32\2.95.3-6\gpcpp.exe'.
> I have tried searching the path with text search in all instaled
> files, with no result. Seems, it is not in an .ini or .cfg file :(

Then it is GPC internal I think. Maybe some part that isn't exposed usually, but somehow gets exposed using {*filter*}shed. (e.g.
because it isn't executed with a special shell that allows forward slashes)

I'm afraid that then the GPC maillist is your ownly hope, and they'll
probably want to see as much output as possible to debug the problem.

GPC's Frank usually monitors here also, but I lately have the feeling he doesn't check news each day.



Thu, 22 Dec 2005 04:56:47 GMT  
 bloodshed

Quote:
> Are you using windows 9x?    There's a path problem whcih has a fix:

> http://gnu-pascal.de/contrib/chief/

That's right, this fixes the problem.
I started compiling some TP7 sourcecode, one very specific that uses
the dos unit and procedure Intr(intno : byte; regs : TRegisters);
can't compile. It says that Intr is never defined. It's seems that
there is no dos unit in gpc, or maybe i should not try to compile
16bit code in a 32bit compiler?

Thanks for your help.

Vasko



Fri, 23 Dec 2005 16:14:29 GMT  
 bloodshed

Quote:



>> Are you using windows 9x?    There's a path problem whcih has a fix:

>> http://gnu-pascal.de/contrib/chief/

> That's right, this fixes the problem.
> I started compiling some TP7 sourcecode, one very specific that uses
> the dos unit and procedure Intr(intno : byte; regs : TRegisters);
> can't compile. It says that Intr is never defined. It's seems that
> there is no dos unit in gpc, or maybe i should not try to compile
> 16bit code in a 32bit compiler?

It's probably win32 compiler vs dos compiler issue, and not fixable easily.
For maximal dos compability you need a dos binary generating compiler.

While 16bit code often needs modifications for 32-bit use, and sometimes
even a lot, it is possible.



Fri, 23 Dec 2005 19:12:47 GMT  
 bloodshed

[snip]

Quote:
> It's probably win32 compiler vs dos compiler issue, and not fixable easily.
> For maximal dos compability you need a dos binary generating compiler.

> While 16bit code often needs modifications for 32-bit use, and sometimes
> even a lot, it is possible.

I probably should make an object file of the unit that uses the TP dos
unit, with TP7, and then link it with the main program in gpc.
Theoreticly, if i wanna further development under {*filter*}shed.

Vasko



Sat, 24 Dec 2005 16:47:02 GMT  
 bloodshed

Quote:


> [snip]

>> It's probably win32 compiler vs dos compiler issue, and not fixable easily.
>> For maximal dos compability you need a dos binary generating compiler.

>> While 16bit code often needs modifications for 32-bit use, and sometimes
>> even a lot, it is possible.

> I probably should make an object file of the unit that uses the TP dos
> unit, with TP7, and then link it with the main program in gpc.

Not possible. 16-bit code with 32-bit code.

Quote:
> Theoreticly, if i wanna further development under {*filter*}shed.

FPC or GPC? ( :-) )

Seriously, the only option is then to rewrite it using specific Windows API
routines (and forget about the dos stuff), or rewrite the unit on top of
GPC/FPC units that are portable across platforms.

The dos code is not usuable on other operation systems except in emulation
mode. Mixing of emulation code and non-emulation code is not possible.

And Windows _IS_ a different operating system. It has its own api. (maybe
there are workarounds for win9x which is somewhat DOS based, but that would
make you have the same problem again as soon as you or your users migrate to
NT)



Sat, 24 Dec 2005 20:46:30 GMT  
 bloodshed

[snip]

Quote:
> Seriously, the only option is then to rewrite it using specific Windows API
> routines (and forget about the dos stuff), or rewrite the unit on top of
> GPC/FPC units that are portable across platforms.

That was my intention in the first place, but ended up with dos unit
not being suported in {*filter*}shed GPC. No problem with FPC. I am
curently developing a menu interface. Standard old fashion, character
screen. My intention is to make it 95% portable in one go on every
platform (TP, FPC, GPC). If i wanned to be only functional, i would
made the code for Turbo Pascal. Infact i did started and made the
whole screen unit in assembly useing BIOS ints, but the whole thing
now has a new dimension for me. It is not only makeing it work, it is
(not matter how unoptimized) makeing it in some pseudo standard
Pascal. The word 'pseudo' meaning i chose Turbo Pascal for
start/standard and later removeing or makeing all modifications on my
code necessery to compile no matter the platform.

The only nonportable potrion of code is a small unit of mine with
functions that read the character and attribute under cursor. I use it
to send the crt window on heap, so it can be later restored. This is a
must do, if you wannt to open a menu while there is already something
going on on the screen.
If only TP's crt unit had functions to read char + attr from activ
screen page, there would be no portability problems. FPC would have
already suport for this on every platform no mater the diferences in
implementation.

Please tell me if i can do the same job by redirecting input and
output devices, and how? By doing that will i be able to use read (c);
(* char *) from console?
I learned (Turbo) Pascal from the book 'TP6 Complete Reference' by
Stephen K.O'Brien and i never encountered (input, output) in the
header of the program.
I need some enlightenment in that matter.

Quote:
> The dos code is not usuable on other operation systems except in emulation
> mode. Mixing of emulation code and non-emulation code is not possible.

Dos box opens in dos-emulation mode on win9x. I do not go further then
console programing but i was forced to try GPC & FPC because they are
available on so many platforms. What is portable is standard, i
think...

Quote:
> And Windows _IS_ a different operating system. It has its own api. (maybe
> there are workarounds for win9x which is somewhat DOS based, but that would
> make you have the same problem again as soon as you or your users migrate to
> NT)

I do not have users :) Gues NT has some command prompt API functions
for that matter.
My point is this. Lets have a standard console i/o unit, and call it
'crt', since there is one, but maybe not a standard, yet. Standard
functions and procedures in that unit will be available on every
developing platform disregarding the hardware specific differences in
implementation. There for, if there is a function that reads the
character code and attribute under the cursor in that 'crt' unit,
there will be absolutly no need for platform specific code to do this.
Every code useing this function will compile on as many platforms GPC
& FPC are available (from win32, Linux... to Amiga).
I am talking of only one function+ in the crt unit, i belive it is
very practical and usefull.

Anyway, all this came to my mind once i thought C++ is more portable
than Pascal.

Vasko

ps - never meant to bug you this mutch :)



Tue, 27 Dec 2005 16:37:46 GMT  
 bloodshed

Quote:


> [snip]

>> Seriously, the only option is then to rewrite it using specific Windows API
>> routines (and forget about the dos stuff), or rewrite the unit on top of
>> GPC/FPC units that are portable across platforms.

> That was my intention in the first place, but ended up with dos unit
> not being suported in {*filter*}shed GPC. No problem with FPC. I am
> curently developing a menu interface. Standard old fashion, character
> screen. My intention is to make it 95% portable in one go on every
> platform (TP, FPC, GPC).

That will be hard. There is nothing universal. FPC is somewhat a bit
compatible with TP/BP (things like Crt), and with GPC (ncurses etc),
but all three will be hard.

Quote:
> If i wanned to be only functional, i would made the code for Turbo Pascal.
> Infact i did started and made the whole screen unit in assembly useing
> BIOS ints, but the whole thing now has a new dimension for me. It is not
> only makeing it work, it is (not matter how unoptimized) makeing it in
> some pseudo standard Pascal. The word 'pseudo' meaning i chose Turbo
> Pascal for start/standard and later removeing or makeing all modifications
> on my code necessery to compile no matter the platform.

I'd not invest any work in keeping BP compability if I wouldn't have very
good reasons (like Femme with embedded processors). 16-bit and Dos are
running out of time, slowly but surely.

Quote:
> The only nonportable potrion of code is a small unit of mine with
> functions that read the character and attribute under cursor.

That's already functionality not available under all operating systems.
(reading the screen)

Quote:
> I use it to send the crt window on heap, so it can be later restored. This
> is a must do, if you wannt to open a menu while there is already something
> going on on the screen. If only TP's crt unit had functions to read char +
> attr from activ screen page, there would be no portability problems. FPC
> would have already suport for this on every platform no mater the
> diferences in implementation.

Yes, via unit Video.

Quote:
> Please tell me if i can do the same job by redirecting input and
> output devices, and how? By doing that will i be able to use read (c);
> (* char *) from console?
> I learned (Turbo) Pascal from the book 'TP6 Complete Reference' by
> Stephen K.O'Brien and i never encountered (input, output) in the
> header of the program.

Input and output aren't defined like that in Borland dialects. That line is
ignored (but TP/BP/FPC doesn't break on that to keep some std pascal
compability)

Input and output are simply file variables defined in the system
unit. Taking them over is possible. For FPC and TP see the Crt unit source
which does that.

Quote:
> I do not have users :) Gues NT has some command prompt API functions
> for that matter.
> My point is this. Lets have a standard console i/o unit, and call it
> 'crt', since there is one, but maybe not a standard, yet. Standard
> functions and procedures in that unit will be available on every
> developing platform disregarding the hardware specific differences in
> implementation. There for, if there is a function that reads the
> character code and attribute under the cursor in that 'crt' unit,

For FPC it is in unit video. See manual for examples. Sb recently reported
problems with it though, but I haven't been able to reproduce it yet.

However Video doesn't automatically trap input and output.

Quote:
> Every code useing this function will compile on as many platforms GPC
> & FPC are available (from win32, Linux... to Amiga).
> I am talking of only one function+ in the crt unit, i belive it is
> very practical and usefull.

It is not a portable function.

Quote:
> Anyway, all this came to my mind once i thought C++ is more portable
> than Pascal.

The problem is in the libraries. Standard C++ doesn't provide this function
either, since it is WAY beyond the scope of a standard implementation.
So under C++ you'll have to tinker with the same libs as in FPC and GPC to
get it working.


Tue, 27 Dec 2005 22:09:33 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Bloodshed Dev-Pas v1.2 question

2. Bloodshed Dev-Pascal error message - please help

3. Bloodshed site?

 

 
Powered by phpBB® Forum Software