(first time I am using the mail list ... I may do it wrong!)

I
have a quite big program (now with more than 200.000 lines), first build with TP7. For example it accesses CGA memory through absolute address ...

Years ago I moved to FPC. And it compiled ok under Windows 98 then under XP.

Now with with a new PC running Windows 8 ... the
compiler bugs. It works fine with small program .... but not with one which executable about 1.5 Mb large (which is my case, I did not checked till which size it works!).

My program should run in prompt command
window of any MS Windows version (compiling on XP machine, the executable runs fine on MS Windows 8 machine)

The bug may not be fixed
soon ... version of the compiler for DOS/GO32v2 is not maintained any more.

through bug tracker I have been told to build the compiler this way (using i386-win32 source and compiler):

cd c:fpc2.6.2-src
set
PATH=c:fpc2.6.2bini386-win32;%PATH%
make clean crossall crossinstall
CPU_TARGET=i386 OS_TARGET=go32v2 BINUTILSPREFIX=
INSTALL_PREFIX=c:fpc2.6.2 FPMAKEOPT="-T 2"

but this does not build the
fpc.exe

it does build go32v2 units in the FPC2.6.2UNITSGO32V2

I
tried to compile the software for win32 (not GO32v2) ... but I got an error on the absolute address syntaxe ... then I tried to use {$mode TP} in the unit where is the absolute address ( TelaCGA : Telas absolute $B800:0000;) ... but it looks like that {$mode ...} does not work as expected. It should be for the current unit ... but ... but next units does not compile any more ... may be because of related units ...

through bug tracker I got these informations which let me think that the job is not simple as I expected:

I BELIEVE THAT THE
CROSS-COMPILER SHOULD NOT BE NECESSARY AND USING THE WIN32 COMPILER DIRECTLY SHOULD BE A BETTER OPTION (even if running under 64-bit Windows as long as I understand it correctly). Obviously, the RTL and packages compiled for GO32v2 are necessary, but these may be installed from our standard FPC release for GO32v2 (as long as using the same release of the Windows compiler, of course), and SOME ADDITIONAL TRICKS MAY BE NECESSARY (e.g. copying the DJGPP assembler and linker to the Win32 directory with the prefix expected by FPC), but otherwise it isn't that difficult.

It´s quite easy to understand that it is not enough to find out my way!

where can I find documentation about the compiler and how to build it?

I appreciate any help.

[snip]

can you install 32 bit Windows XP under a Virtual Machine, like Virtualbox, then FPC on that? The IV drip would be extended... ;)

-L.

On Wed, September 18, 2013 18:48, Philippe wrote:

Hello Philippe,

.
.

You are lucky that your DOS application still runs OK under MS Windows 8, but the issue you face with our compiler suggests, that you should not expect that this will stay that way.

The bug may not be fixed soon ... version of the compiler for DOS/GO32v2 is not maintained any more.

The problem is not maintenance of the DOS/GO32v2 compiler (if I understand you correctly, it compiles your program correctly except when running under MS Windows 8), but simply the fact that MS Windows 8 is very far from DOS for which is that version created - see a FAQ about support of the DOS compiler under MS Windows (the difficulties increase with each MS Windows version).

through bug tracker I have been told to build the compiler this way (using i386-win32 source and compiler): cd c:fpc2.6.2-src

.
.

but this does not build the fpc.exe

Yes, you don't need a new fpc.exe binary - you should use the one included in your FPC installation for MS Windows.

it does build go32v2 units in the FPC2.6.2\UNITS\GO32V2

That is good, you obviously need those units (preferably, you need them in the same directory tree where you MS Windows compiler and units for the MS Windows platform reside). As a possibly easier option (assuming that you use the officially released version), you can also use the compiled units distributed with the FPC release and install them into the same directory. If the (DOS) installer does not work for you (e.g. it crashes similarly to the DOS compiler), you can still unpack the respective ZIP files (included in the big ZIP file) manually.

If you use text mode, you can change the direct video adapter memory access to access of a video buffer provided in unit Video (available for most supported platforms). If you use graphics mode, porting becomes somewhat more difficult and you need to decide whether to use the standard RTL unit Graph (TP-compatible, rather limited, but probably sufficient for something originally targetting a CGA adapter), platform-specific API (e.g. Win32 API in your case), or one of multi-platform GUI frameworks.

Yes, it is. ;-) These are the things I didn't feel like discussing in the bug tracker notes:

1) You don't need a cross-compiler if you don't run/use a (native) Win64 compiler under MS Windows. I assume that this is not the case, but I couldn't know for sure - hence the "...should not be necessary...".

2) You still need at least a linker for the GO32v2 target (FPC internal linker does not support this target) and that is the somewhat tricky part. There are two basic options. The simpler one would be using the (DOS) ld.exe included with our DOS release (placed in bin\go32v2). However, since it is still a DOS application, it might crash the same way as our compiler does. Moreover, the Win32 compiler searches this linker in the Win32 binary directory (bin\i386-win32) and expects it to be named go32v2-ld.exe by default. The default directory may be overridden using compiler option -FD and the expected prefix (go32v2-) using option -XP, but the easiest option is probably simply copying the original bin\go32v2\ld.exe to bin\i386-win32\go32v2-ld.exe. If that does not work for you, you need a special cross-compiled version of GNU binutils for the GO32v2 target - that is not something officially provided by the FPC team, but you can download such a version from the directory with contributed files as e.g.
ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw/binutils-2.15-win32-i386-go32.zip and unpack them into bin\i386-win32 as before. However, there are still glitches with that version since the files still need to be renamed (from i386-go32-ld.exe to go32v2-ld.exe) and they expect a different syntax/command line options than the standard DJGPP version used for the GO32v2 target (as a workaround, you could then compile using FPC option -s and edit the generated file ppas.bat by replacing "@link.res" with linker options included in the generated file "link.res" (concatened to a single line).

I hope that the length of the previous text (which still gives space to additional questions) clarifies my hesitation for discussing this topic in bugtracker notes.

where can I find documentation about the compiler and how to build it?

As mentioned previously, you shouldn't need to build it in the first place. If you still want to do so, there is a file named "buildfaq.pdf" (e.g. search our Wiki for it), but don't expect easy reading.

Hope this helps; feel free to ask if you come across additional questions.

Tomas

And especially 16-Bit applications aren't working on 64-Bit variants of Windows at all.

Hmm? Looking at compiler/systems/t_go32v2.pas I would say GO32v2 does have an internal linker?!

Regards,
Sven

It's not necessarily a problem of your executable size, but the problem is the size/amount of units, because when compiling the compiler needs to keep all their interface meta-data in RAM.

My program should run in prompt command window of any MS Windows version (compiling on XP machine, the executable runs fine on MS Windows 8 machine)

This will however not work on a 64-bit systems as the NT Virtual DOS Machine (ntvdm.exe) is not supported there anymore.

The bug may not be fixed soon ... version of the compiler for DOS/GO32v2 is not maintained any more.

It's still maintained. Though it's mostly used on DOS/GO32v2 systems and likely with less big projects.

As Tomas wrote you'll likely not be able to convert the CGA code 1:1 to Windows as there this absolute addressing mode is not supported. And yes, the additional compile errors are likely because that one unit could not be compiled.

Regards,
Sven

In our previous episode, Sven Barth said:

It's still maintained. Though it's mostly used on DOS/GO32v2 systems and likely with less big projects.

One of the problems with dos maintenance is that there are very few bugreports with source, and IDE problems are not always reproducable.

Sven Barth wrote

On 19.09.2013 17:28, Tomas Hajny wrote:

.
.

Have you checked it in fixes or trunk? In any case, I've tried it directly with the 2.6.2 binary before posting - even if I pass -Xi explicitly, the compiler still complains about go32v2-ld.exe not found if it is not accessible (and linking fails). I believe that Sergei may have fixed / enabled it for GO32v2 in trunk (but my memory may serve me wrong, of course).

Tomas

In our previous episode, Tomas Hajny said:

I also started testing when I saw it, and I could cycle trunk with -Xi.

I'm not sure how far along it is, and if it is default. (is the internal linker always default if available?)

Yes, the internal linker is used by default. See options.pas, line 3246:

=== code begin ===

   { Force use of external linker if there is no
     internal linker or the linking is skipped }
   if not(cs_link_extern in init_settings.globalswitches) and
      ((target_info.link=ld_none) or
       (cs_link_nolink in init_settings.globalswitches)) then
     include(init_settings.globalswitches,cs_link_extern);

=== code end ===

Regards,
Sven

Ehm, yes, trunk only. Sergei implemented it in revision 21435 at 30th May 2012.

Regards,
Sven

In our previous episode, Sven Barth said:

determines if the internal linker is used. (so not just its registration).

Anyway thanks, it is clearer now.

sorry ... delayed answer ... I don´t felt very well these days .... and this subject is a bit difficult for me ... but I will give time this week to read all I received ... and find out a way ... I´ll write later this week

any way, I thank you very much all for your help!

Philippe

Sven Barth wrote

On

Philippe wrote

> (first time I am using the mail

list ... I may do it wrong!) I have a quite big program (now with more than 200.000 lines), first build with TP7. For example it accesses CGA memory through absolute address ... Years ago I moved to FPC. And it compiled ok under Windows 98 then under XP. Now with with a new PC running Windows 8 ... the compiler bugs. It works fine with small program .... but not with one which executable about 1.5 Mb large (which is my case, I did not checked till which size it works!).

It's not

necessarily a problem of your executable size, but the problem

is the

size/amount of units, because when compiling the compiler needs

to

keep all their interface meta-data in RAM.

> My program should run

in prompt command window of any MS Windows version (compiling on XP machine, the executable runs fine on MS Windows 8 machine)

This

will however not work on a 64-bit systems as the NT Virtual DOS

Machine (ntvdm.exe) is not supported there anymore.

I am back !!! (a bit sick ... teeth ...)

I am now trying to move
to win32. At first leaving crt unit, moving to video unit.

Problem!(?)
... I was using window, gotoxy and so on ... and I don´t find anything similar with video unit!

Sven Barth wrote

Am 19.09.2013 22:46, schrieb Tomas Hajny: > On Thu,

Sven Barth wrote

> >> On 19.09.2013

Tomas Hajny wrote

> . . > >>> 2) You still need at least a

linker for the GO32v2 target (FPC internal linker does not support this target) and that is the somewhat tricky part.

>> Hmm? Looking at

compiler/systems/t_go32v2.pas I would say GO32v2 does have an internal linker?!

> Have you checked it in fixes or trunk? In any case, I've

tried it directly with the 2.6.2 binary before posting - even if I pass -Xi explicitly, the compiler still complains about go32v2-ld.exe not found if it is not accessible (and linking fails). I believe that Sergei may have fixed / enabled it for GO32v2 in trunk (but my memory may serve me wrong, of course).

Ehm, yes, trunk only. Sergei implemented it

in revision 21435 at 30th

First of all, what do you try to solve by moving from unit Crt to unit Video? I suggested using unit video as a substitution of your original direct access to video adapter memory. Partial alternative of GotoXY exists in unit Video - there is SetCursorPos. However, there is no direct support for Window and thus the addressing is in absolute coordinates, not relative to the defined window. Using direct video memory access (i.e. very low-level approach) together with high-level routines like Window, etc., is a bit strange. Units Video and Crt are not very compatible to each other at the moment, unfortunately (although the incompatibility may not be as bad on Win32 as on some other platforms). Nevertheless, you may try it. Otherwise, you'd need either to create your own alternatives of Window, etc., based on unit Video, or to avoid using the solution based on directly addressing video memory/buffer.

Tomas

I really assumed that I had to choice between video unit and crt unit ...

my old unit which interfaced the video must be updated to be compiled for win32.

I already though about to create my window
procedure and my gotoxy procedure ... this way I may not have to make a lot of changes in my program.

I missed SetCursorPos ... thanks a lot

My first step, anyway, is to verify it is compiling for win32! ... later I´ll make more changes and all the adjustments.

Philippe

On

Tomas Hajny wrote

On Sat, October

Philippe wrote

> I am back !!! (a bit sick ... teeth

...) I am now trying to move to win32. At first leaving crt unit, moving to video unit. Problem!(?) ... I was using window, gotoxy and so on ... and I don´t find anything similar with video unit!

First of all,

what do you try to solve by moving from unit Crt to unit

Video? I

suggested using unit video as a substitution of your original

direct

access to video adapter memory. Partial alternative of GotoXY

exists

in unit Video - there is SetCursorPos. However, there is no direct

support for Window and thus the addressing is in absolute coordinates, not

relative to the defined window. Using direct video memory access

(i.e.

very low-level approach) together with high-level routines like

Window,

etc., is a bit strange. Units Video and Crt are not very

compatible to

each other at the moment, unfortunately (although the

incompatibility may

not be as bad on Win32 as on some other

platforms). Nevertheless, you may

try it. Otherwise, you'd need either

to create your own alternatives of

Window, etc., based on unit Video,

or to avoid using the solution based on

directly addressing video

memory/buffer.

Tomas

it compiles and links ... still a lot of stuff to write and a bunch to adjust!!!!

first tests ... first suprises!!!

but it compiles and
runs ... till the fisrt bug during first steps ...

Philippe

On Sat,

Tomas Hajny wrote

On Sat, October 5,

Philippe wrote

> I am back !!! (a bit sick ... teeth

...) I am now trying to move to win32. At first leaving crt unit, moving to video unit. Problem!(?) ... I was using window, gotoxy and so on ... and I don´t find anything similar with video unit!

First of all,

what do you try to solve by moving from unit Crt to unit

Video? I

suggested using unit video as a substitution of your original

direct

access to video adapter memory. Partial alternative of GotoXY

exists

in unit Video - there is SetCursorPos. However, there is no direct

support for Window and thus the addressing is in absolute coordinates, not

relative to the defined window. Using direct video memory access

(i.e.

very low-level approach) together with high-level routines like

Window,

etc., is a bit strange. Units Video and Crt are not very

compatible to

each other at the moment, unfortunately (although the

incompatibility may

not be as bad on Win32 as on some other

platforms). Nevertheless, you may

try it. Otherwise, you'd need either

to create your own alternatives of

Window, etc., based on unit Video,

or to avoid using the solution based on

directly addressing video

memory/buffer.

Tomas

"Philippe" wrote

Problem!(?) ... I was using window, gotoxy and so on ... and I don´t find

anything similar with video unit!

I don't know if this would be useful to you, but I've been working on a modernized CRT for some time:

- https://github.com/tangentstorm/xpl/blob/master/code/kvm.pas
- http://tangentstorm.github.io/xpl/kvm.pas.html ( literate programming style tour of the code )
These support unicode output, 256 foreground and background colors, and (eventually) italics, bold, etc.

They don't work with the video unit or the normal windows console, because neither provide the above features.

However, I also have implementations for SDL and ZenGL here:

- https://github.com/sabren/b4/blob/master/ng/rxgl_sdl.pas
- https://github.com/sabren/b4/blob/master/ng/rxgl_zen.pas
- https://github.com/sabren/b4/blob/master/ng/rt_term.pas

These allow mixing console text with vector graphics powered by aggpas. Looks like I haven't declared that they implement the kvm interfaces yet, but they should be very similar.

All of this is MIT-licensed so feel free to do whatever with it.

-Michal
http://tangentstorm.com/

really thanks, but my needs are quite basic, and I found my way.

but I keep the link ... me be usefull later!

Thanks

Philippe

On

Michal Wallace wrote

On Oct 5, 2013

"Philippe" wrote

> Problem!(?) ... I was using window,

gotoxy and so on ... and I don´t find anything similar with video unit!

I don't know if this would be useful to you, but I've been working

on a modernized CRT for some time:

-

https://github.com/tangentstorm/xpl/blob/master/code/kvm.pas [2]

-

http://tangentstorm.github.io/xpl/kvm.pas.html [3] ( literate programming style tour of the code ) These support unicode output, 256 foreground and background colors, and (eventually) italics, bold, etc.

They don't work with the video unit or the normal windows console,

because neither provide the above features.

However, I also have

implementations for SDL and ZenGL here:

-

https://github.com/sabren/b4/blob/master/ng/rxgl_sdl.pas [4]

-

https://github.com/sabren/b4/blob/master/ng/rxgl_zen.pas [5]

-

https://github.com/sabren/b4/blob/master/ng/rt_term.pas [6]

These

allow mixing console text with vector graphics powered by aggpas.

Looks like I haven't declared that they implement the kvm interfaces yet, but they should be very similar.

All of this is MIT-licensed

so feel free to do whatever with it.

-Michal

http://tangentstorm.com/ [7]

Links:
------
[1]

[2]
https://github.com/tangentstorm/xpl/blob/master/code/kvm.pas [3]
http://tangentstorm.github.io/xpl/kvm.pas.html
[4]
https://github.com/sabren/b4/blob/master/ng/rxgl_sdl.pas [5]
https://github.com/sabren/b4/blob/master/ng/rxgl_zen.pas [6]
https://github.com/sabren/b4/blob/master/ng/rt_term.pas [7]
http://tangentstorm.com/