Do you have a small bugfix?

[Allan Mertner]

If I manage to do a build of VP for general release, do you have a bugfix to some part of VP - the RTL being the most obvious candidate - that I should include?

I have already made the small change to VpSysW32 from the thread started by Robert - if you have any others, please post them as a reply to this thread. Please include a description of the change and include/attach the changed source and I will review it.

Note that this is not a general call for a list of bugs to fix or features to add - I'm still not working on VP :) I fixed a bug in the linker the other day though, and thought it would be nice to do a refresher build including that and other small changes that have accumulated over the years.

Thanks,
Allan

[Alcatiz]

Hi Allan !

A new build for my favourite compiler, it's such a good news !

There is a missing field (not documented in the MSDN !) in the TServEnt structure, in the Winsock unit :
PServEnt = ^TServEnt;
TServEnt = packed record
s_name : PChar;
s_aliases : ^PChar;
s_port : Smallint;
s_pad1 : Smallint; // Additional field
s_proto : PChar;
end;
Regards

Alcatiz.

[Allan Mertner]

It looks like you are right; on my system, it returns $BAAD in the pad value - and without it, the s_proto pointer is invalid.

Strangely, I can't find reference to this anywhere - it looks to me as it nobody uses the s_proto field. If they did, the programs would fall over every time!

Unless someone objects, I'll make this change.

Thanks,
Allan

[Stefan Weber (AH)]

Hi Allan,

first of all, thank you for considering to update VP.
I hope you won't mind if I will mirror the new release on my HP http://ndn.muxe.com/download/ when it's available.

Now, I have made a lot of changes and bug fixes over the past 5 years to the whole VP
RTL (W32/D32/LNX, excluding OS2!). All my changes are based on the updated VP RTL made by Veit Kannegieser to support DPMI32. I also merged in the second VP RTL release by VK, which is 1 or 2 years old (not completely though, I didn't want to break any core functionality).
I have rewritten PE2ELF. And it's possible to use VP/W32 in pure DOS with the help of the the HX-DOS Extender (I wrote a little batch file that will do the necessary work).
VP/LNX executables now also run in BSD to some extent (at least they did when I worked on it the last time...)

Well, all in all this is quite some stuff to add to the VP package.
It probably won't be easily merged with your VP files. I don't even know if you can still call this merging, since
(esp. for the LNX target) your and my files may be almost 100% different.

I am quite busy at the moment, so I cannot help out with RTL merging right now.

Maybe you would like to have all the modified files and take a look yourself?

We could at least add the D32 target to the new package.

All the best,
Stefan / AH

[Allan Mertner]

Hi Stefan,

VP remains completely free of course, and if you have a way of mirroring the download then that is great with me.

I do have some of the early D32 and LNX code in VP of course, but I'm sure it has moved on quite a bit. D32 isnt really a focus of mine though, and I'm happy for Veit to be the one that supplies the parts for that platform :)

Some of the big changes are probably dangerous for me to include if they involve large changes as I have no real way of testing them. On the other hand, I would be happy to include smaller fixes or obvious, tested improvements. If you send me what you have, I'll try to take a look.

Would anyone else on the forum perhaps be able to give a hand in figuring out what to include?

Cheers,
Allan

[Allan Mertner]

Hi Stefan,

I have had a look at the files you have submitted, and there are a lot of changes. I intend to take a look and will probably include most of them - but some of them are not exactly clear and some I don't agree with :)

I also noticed that you have reformatted all of the files to use TABs instead of spaces. That's nice to save space but is a bad idea from almost every other perspective, since the indenting works only if everybody agrees that a TAB is 8 spaces. And not everybody agreed, so I'll definitely revert back to spaces.

If I have questions about some of the changes, can I ask you directly? I might just open a separate thread for that.

Thanks,
Allan

[Stefan Weber (AH)]

Hi again!

I have uploaded my VP RTL here: http://ndn.muxe.com/download/file/22

Please note that this archive contains *only* the files that differ from the standard VP 2.1.279 installation plus the DPMI32 update #1 by VK.
I hope you will be able to use some of the files.

Bye,
Stefan / AH

[Marco van de Voort]

Maybe add some headers to the windows version ? I don't know exactly which ones you have now, but you could at least be able to take the fairly procedural commctrl and wininet units from FPC.

Maybe others too, if you clean out some blocks of COM interface and an occasional int64 use here and there, and maybe it will help someone.

[Stefan Weber (AH)]

Hi again Allan.

Found another little problem that might be of interest:
While porting ipstack for FPC by Diego De Marco to VP I tried to add
type
DWord = Longint;
to system.pas.
If I add it right to the beginning
unit System;
interface
type
...
and trying to compile the RTL this happens:
- Linking VpSysLow to new System unit
Virtual Pascal Version 2.1.279 Copyright (C) 2000-2004 vpascal.com
Built in London, UK on 9 May 2004 by [e-mail]
F:\VP\source\rtl\use32.pas(26)
F:\VP\source\d32\dpmi32df.pas(296)
F:\VP\source\rtl\strings.pas(557)
F:\VP\source\d32\mthread.pas(610)
F:\VP\source\d32\dpmi32.pas(1459)
F:\VP\source\rtl\dos.pas(677)
F:\VP\source\d32\d32res.pas(188)
F:\VP\source\rtl\exehdr.pas(1553)
F:\VP\source\rtl\windos.pas(536): Error 164: Internal compiler error #2
finalization
^

If I add this right at the end of the interface part, before the implementation keyword,
everything works fine. Strange.

Maybe the DWORD type should be default in system.pas?
I haven't worked much with this yet, maybe some compatibility errors with other type defs will occur?

All the best,
Stefan / AH

[Marco van de Voort]

Sounds like DWord is already defined in some windows unit. It is a windows type afaik. But FPC does have it in system

I'd try to find which windows unit it defines and alias it to system.dword there..

[Stefan Weber (AH)]

This may be true, still it doesn't explain why it works when I simply move the location
of the definition away from the start of the unit. There are no uses clauses in between in
system.pas

exehdr f.ex. defines DWord too. Removing this doesn't help.

[Allan Mertner]

If I remember correctly, the System unit is special in several regards because it needs to interface directly to some bits written in assembly code. If you introduce a new symbol in the System unit, you need to make sure that it is defined in the right place - there is a file that describes all of the symbols in this unit and the order is important.

If you add the definition to the end, the order of all the other symbols is preserved which is probably why it works.

In general, the best thing is to not modify System :)

Allan

[Stefan Weber (AH)]

Hi!

Well... sorry, I cannot resist :)
Unfortunately there's no way to tell VP to implicitly include a unit, like VP does internally with system or use32 (does FPC allow this? ;)).
This would be perfect for porting applications.... (don't worry, it's no feature request :)

So, I've added the following to system.pas, right before the implementation keyword:
{More basic fixed size integer data types}
type
DWord = LongInt; {Free Pascal}
QWord = Comp; {Free Pascal}
LongWord = LongInt; {Delphi 4+}

Int8 = ShortInt;
UInt8 = Byte;
Int16 = SmallInt;
UInt16 = Word;
Int32 = LongInt;
UInt32 = LongWord;
Int64 = Comp; {Delphi 4+}
UInt64 = Comp;

Btw, you can override every type definition made in system.pas in external units without VP complaining. I guess that's a feature, I don't mind. :)

All the best,
Stefan / AH