Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order
Laaca(R)

Homepage

Czech republic,
30.12.2016, 23:54
 

Freepascal 3.0.2rc1 (Announce)

It is not yet announced on the official FPC webpage but the release candidate for new version is available for download from FTP servers. Here

I tried it only very briefly do far (the DOS, GO32V2 version, of course) however after many many years and many releases it seems to work without problems just out from the box.
The DOS IDE is included, even with debugging GDB support (with GDB 7.0!) and VESA support is on.
The example programs I tried compile without problems and run.
The only problem I noticed are the examples for PTC library. I tried FIRE.PP and FLOWER.PP and it ended with RTE-216. But maybe is it something trivial.
So, the FPC 3.0.2rc1 is worth to try!

---
DOS-u-akbar!

Rugxulo(R)

Homepage

Usono,
08.01.2017, 20:14

@ Laaca

Free Pascal 3.0.2 (rc1)

> the release candidate for new [FPC 3.0.2] version is available
>
> The example programs I tried compile without problems and run.
>
> So, the FPC 3.0.2rc1 is worth to try!

The installer still gets confused due to "doc/fpc/readme-jvm.txt",
which is in BASEDOS.ZIP, which makes it think it needs LFNs.
So if you try to install with no LFNs available, it won't install
properly unless you manually check the "BASE" check box. Or delete
that text file from the .ZIP before running the installer.

It also still claims you need GNU Linker and GNU Assembler, but AFAIK, you
don't (except maybe rebuilding RTL??).

marcov(R)

12.01.2017, 15:23

@ Rugxulo

Free Pascal 3.0.2 (rc1)

> It also still claims you need GNU Linker and GNU Assembler, but AFAIK, you
> don't (except maybe rebuilding RTL??).

Yes, the assembler for rebuilding the RTL, specially the assembler binary startup. The GNU Linker might be useful if you link with DJGPP libs that contain something the internal linker doesn't grok.

Rugxulo(R)

Homepage

Usono,
23.02.2017, 16:17

@ marcov

Free Pascal 3.0.2 (final?)

Okay, seems 3.0.2 final has apparently been released (and announced), but I don't see BASEDOS.ZIP anywhere (e.g. not on SF.net). Yet it's still mentioned inside install.dat too. I haven't actually tried installing, but I'm pretty sure this is a mistake! (But dos302full.zip at least has basesrc.zip inside it.)

marcov(R)

27.02.2017, 13:06

@ Rugxulo

Free Pascal 3.0.2 (final?)

> Yet it's still mentioned inside install.dat too. I haven't actually tried
> installing, but I'm pretty sure this is a mistake! (But dos302full.zip at
> least has basesrc.zip inside it.)

confirmed. Afaik the bigger ones are generated from the single directory by a script, so maybe it was a mistake uploading the single ones.

I mailed core to ask where it went ;-)

marcov(R)

27.02.2017, 14:03

@ marcov

Free Pascal 3.0.2 (final?)

Should be fixed. If more files are missing please report.

Rugxulo(R)

Homepage

Usono,
28.02.2017, 19:15

@ marcov

Free Pascal 3.0.2

> Should be fixed. If more files are missing please report.

Yes, it's there now and seems to install and work fine (although it still has the readme-jvm.txt installation quirk).

The only missing file I see is the FPU emulator: "Floating point processor emulator: wemu387.dxe (60 kB)" ("550: No such file or directory").

The website also has a few bad links and typos ("Game Bod Advance"). E.g. Haiku erroneously points to "pub/fpc/dist/3.0.0/i386-freebsd/fpc-3.0.0.i386-haiku.tar" (which isn't found in the FreeBSD subdir, obviously).

marcov(R)

01.03.2017, 11:34

@ Rugxulo

Free Pascal 3.0.2

> > Should be fixed. If more files are missing please report.
>
> Yes, it's there now and seems to install and work fine (although it still
> has the readme-jvm.txt installation quirk).

Somehow my reply got lost (auto logout end of the month or so?)

Anyway, I fixed the typos, removed readme-jvm from separate manually (and will ask how to rebuild the zips later, I want to be able to do that myself)

I also started with a fix for the readme-jvm.txt by adding the following to fpcbuild/Makefile.fpc

$(MKDIR) $(INSTALL_DOCDIR)
-$(COPY) $(addprefix $(CVSINSTALL)/doc/,*.txt copying* license* faq.*) $(INSTALL_DOCDIR)
# but don't include readme-jvm.txt for lfn challenged targets (gives problems unzipping)
ifneq ($(findstring $(OS_TARGET),$(LIMIT83fs)),)
$(DEL) $(INSTALL_DOCDIR)/readme-jvm.txt
endif

(The bit after the # comment). Maybe additional paths are needed (fpc/ ?) there, but I can't test atm (64bit windows))

Anyway, that is something to streamline the issue for future releases.

Rugxulo(R)

Homepage

Usono,
02.03.2017, 22:17

@ marcov

Free Pascal 3.0.2

Thanks for your efforts. BTW, I again mirrored the obvious stuff to iBiblio for FreeDOS.

> ifneq ($(findstring $(OS_TARGET),$(LIMIT83fs)),)
> $(DEL) $(INSTALL_DOCDIR)/readme-jvm.txt
> endif

You could always instead rename it to "readme.jvm" or "read-jvm.txt". Of course, I doubt Go32v2 users will ever care for Java anyways.

BTW, you uploaded wmemu387.dxe but left the old text (and download link) with the wrong name (wemu vs. wmemu):

> Floating point processor emulator: wemu387.dxe (60 kB)
> ftp://freepascal.stack.nl/pub/fpc/dist/3.0.2/i386-go32v2/separate/wmemu387.dxe

marcov(R)

03.03.2017, 15:56

@ Rugxulo

Free Pascal 3.0.2

> You could always instead rename it to "readme.jvm" or "read-jvm.txt". Of
> course, I doubt Go32v2 users will ever care for Java anyways.

Indeed, and it is less discussion and "how do I open this" noise this way. Moreover the technique can be recycled to exclude future lfn troubles on the creation side.

> BTW, you uploaded wmemu387.dxe but left the old text (and download link)
> with the wrong name (wemu vs. wmemu):

Fixed in SVN, will propagate tonight.

Laaca(R)

Homepage

Czech republic,
24.03.2017, 21:13
(edited by Laaca, 24.03.2017, 22:27)

@ marcov

Free Pascal 3.0.2 - external linker?

I am very busy these days but from time to time I a little bit experiment with FPC 3.0.2
As I reported into FPC there is a issue (No. 0030548) that FPC compiled programs (I mean for DOS) can't be compiled with UPX because the COFF header changed a little bit.
It is bug of UPX not FPC bug and I reported it into UPX developer.
However:
I thought that it is caused by calling some external DJGPP linking utility. But the DJGPP support files (in the \BIN\GO32V2 directory) are the same as in my favorite FPC version 2.4.2
And even if I use the external linking switch (FPC.EXE -Xe test.pas) the generated .EXE is compatible with UPX.
So it is a bit unexpected for me. FPC now uses some incompatible DJGPP code inside itself (inside FP.EXE and FPC.EXE) and no external utilities has nothing to do with it?

---
DOS-u-akbar!

marcov(R)

28.03.2017, 10:21

@ Laaca

Free Pascal 3.0.2 - external linker?

> And even if I use the external linking switch (FPC.EXE -Xe test.pas) the
> generated .EXE is compatible with UPX.

Is this a typo, or do you mean INcompatible here?

> So it is a bit unexpected for me. FPC now uses some incompatible DJGPP code
> inside itself (inside FP.EXE and FPC.EXE) and no external utilities has
> nothing to do with it?

I've no idea. There are always things changing, and it might be an rearrangement of tables lead to this. The programs work, so it will pass any testsuite.

That a 3rd party utility regressed in recent versions should be laid primarily at UPX's door, that has nothing to do with FPC's DJGPP compatibility or not.

But there is a bugreport, so if sb wants to look in to it.... It might be something simple like the order of various sections written out to the link.res or so.

Laaca(R)

Homepage

Czech republic,
28.03.2017, 22:59

@ marcov

Free Pascal 3.0.2 - external linker?

> > And even if I use the external linking switch (FPC.EXE -Xe test.pas) the
> > generated .EXE is compatible with UPX.
>
> Is this a typo, or do you mean INcompatible here?

It is no typo at all.
"FPC -Xi test.pas" makes binary which is not compatible with UPX.
"FPC -Xe test.pas" produces binary which has no problem with UPX.

-Xe parameter calls utility LD.EXE (older version 2.17) which is the same version like in f.e. FPC 2.4.2

No parameter or -Xi parameter calls own FPC linking code. So it shows that this incompatibility has nothing to do with DJGPP 2.05 incompatibility, resp. Binutils 2.23.2 incompatibility (which can be observed f.e. here)

I suspect some change in the OGCOFF.PAS file in \COMPILER subdirectory
The change was done after FPC 2.6.4 which is after March 2014
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/ogcoff.pas?view=log

It seems that UPX checks the COFF header very strictly and rejects all deviations.

However the modification in DJGPP/BinUtils is planned and documented but the FPC incompatibility seems to be some unplanned sideffect.

---
DOS-u-akbar!

marcov(R)

29.03.2017, 13:08

@ Laaca

Free Pascal 3.0.2 - external linker?

> "FPC -Xi test.pas" makes binary which is not compatible with UPX.
> "FPC -Xe test.pas" produces binary which has no problem with UPX.


Clear, so it is internal linker vs external linker.


> No parameter or -Xi parameter calls own FPC linking code. So it shows that
> this incompatibility has nothing to do with DJGPP 2.05 incompatibility,
> resp. Binutils 2.23.2 incompatibility (which can be observed f.e.
> here)

The point was that the incompatibility was only with UPX, not DJGPP or its utils itself.

> I suspect some change in the OGCOFF.PAS file in \COMPILER subdirectory
> The change was done after FPC 2.6.4 which is after March 2014
> http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/ogcoff.pas?view=log
>
> It seems that UPX checks the COFF header very strictly and rejects all
> deviations.

The whole dos internal linker is post 2.6.x afaik. And I wouldn't call it strictly, but merely a subset hacked till it worked with DJGPP.

This has happened before, *nix derived tools are hardly tested with anything else than what gcc supports. Often (like here) not even attempt was made to support the standard fully.

Rugxulo(R)

Homepage

Usono,
01.04.2017, 23:01

@ Rugxulo

Free Pascal 3.0.2

> The website also has a few bad links ...

Just since I accidentally stumbled upon this post (on fpc-devel, March 20th), it seems you didn't notice (yet), so I'm reminding you here.

It seems x86_64/linux is pointing to a missing rpm/ subdir for some downloads, e.g. fpc-3.0.2-1.x86_64.rpm ("550: No such file or directory").

Laaca(R)

Homepage

Czech republic,
07.04.2017, 01:51

@ marcov

Free Pascal 3.0.2 - bug in the PTC library

I found another bug in the DOS version of FPC.
For this time it is not in the FPC itself but in the package PTC. It is a decent multiplatform graphic library written in modern style with use of advanced FPC features.

The bug was in the PTC initialization code and can be quite easily fixed. Details in the bugreport http://bugs.freepascal.org/view.php?id=31645

---
DOS-u-akbar!

marcov(R)

09.04.2017, 13:36

@ Laaca

Free Pascal 3.0.2 - bug in the PTC library

> The bug was in the PTC initialization code and can be quite easily fixed.
> Details in the bugreport
> http://bugs.freepascal.org/view.php?id=31645

My guess in the past 16-bit mnemonics in 32-bit code automatically map to their 32-bit equivalents.

If you ran into problems now, it might be a side effect of the 16-bit target being added and implementing proper 16-bit support (if it uses the same asm parser as 32-bit, don't know that for sure)

Anyway, fixed in SVN, please test

Rugxulo(R)

Homepage

Usono,
05.05.2017, 10:18

@ marcov

Free Pascal - May 2017 SourceForge.net Project of the Month

Just FYI: FPC - SourceForge.net "Community Choice" Project of the Month

marcov(R)

06.05.2017, 17:48

@ Rugxulo

Free Pascal - May 2017 SourceForge.net Project of the Month

> Just FYI:
> FPC
> - SourceForge.net "Community Choice" Project of the Month

I know :-)

Anyway FYI, FPC is preparing an emergency 3.0.4 release, hopefully to come out in the next 6-8 weeks. (yes, 3 months is "emergency speed" in the project:-D )

The problems are in the back trace of debug information of ELF (*nix) targets only, but since that is half of the targets, it was decided to make it a full release of all targets that want to. Over 300 revs have been merged, but most are not core RTL and compiler (specially the pascal parser in libraryform fcl-passrc, has seen enormous progression, mostly because a pascal-to-javascr*** compiler uses it)

Back to the board
Thread view  Mix view  Order
15112 Postings in 1359 Threads, 247 registered users, 11 users online (0 registered, 11 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum