Re: [Freedos-devel] FreePascal near to far pointer conversion

[Danilo Pecher via Freedos-devel]

As far as I know the earlier Turbo-Pascal compilers (I think 5.5 and
earlier) have been freeware'd years ago. They can natively compile
16bit code on Freedos and might be worth a try. You can find even
ancient versions of TP, like 3.0 on winworldpc, and I actually quite
like to go down memory lane once in a while, although I have ported
most of my projects to Watcom C by now.

cheers, Hippo

On Thu, 9 Nov 2023 at 23:44, Bernd Böckmann via Freedos-devel
 wrote:
>
> Btw, when compiling in large memory model via
>
> fpc -Wmlarge
>
> the pointer errors when compiling keyb are gone. There are some 20
> remaining compile errors. Perhaps these can be solved.
>
> Bernd
>
> On 09.11.2023 23:38, Bernd Böckmann via Freedos-devel wrote:
> > Hello Aitor,
> >
> > > Could you please post the exact message you got from the compiler?
> >
> > For something like this "FarPointer(@Buffer)" I get the following
> > error message:
> >
> > "Error: Illegal type conversion: "Pointer" to "FarPointer""
> >
> > My opinion is that this should be supported by the compiler, because
> > it is well defined for the small memory model I am working in.
> >
> > I looked into the keyb source code and tried to compile it with
> > FreePascal. One problematic line is for example:
> >
> >  PWord ( ptr(m-1,1) )^ := m;{ make it self-parented }
> >
> > Here, Ptr emits a far pointer, and PWord would cast this to a near
> > pointer. FreePascal complains about it.
> >
> > BUT the following at least gets accepted by the compiler:
> >
> > type PFarWord = ^Word; far;
> >
> >  PFarWord ( ptr(m-1,1) )^ := m;{ make it self-parented }
> >
> > This converts it to a typed FAR pointer, which than can be de-referenced.
> >
> > What is more concerning are error messages like:
> >
> > "Warning: Use of +offset(%ebp) is not compatible with regcall
> > convention", since there is not a trace of 32 bit instructions in the
> > code.
> >
> > Bernd
> >
> >
> >
> >
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Bernd Böckmann via Freedos-devel]

Btw, when compiling in large memory model via

fpc -Wmlarge

the pointer errors when compiling keyb are gone. There are some 20 
remaining compile errors. Perhaps these can be solved.


Bernd

On 09.11.2023 23:38, Bernd Böckmann via Freedos-devel wrote:

Hello Aitor,

> Could you please post the exact message you got from the compiler?

For something like this "FarPointer(@Buffer)" I get the following 
error message:


"Error: Illegal type conversion: "Pointer" to "FarPointer""

My opinion is that this should be supported by the compiler, because 
it is well defined for the small memory model I am working in.


I looked into the keyb source code and tried to compile it with 
FreePascal. One problematic line is for example:


 PWord ( ptr(m-1,1) )^ := m;    { make it self-parented }

Here, Ptr emits a far pointer, and PWord would cast this to a near 
pointer. FreePascal complains about it.


BUT the following at least gets accepted by the compiler:

    type PFarWord = ^Word; far;

 PFarWord ( ptr(m-1,1) )^ := m;    { make it self-parented }

This converts it to a typed FAR pointer, which than can be de-referenced.

What is more concerning are error messages like:

"Warning: Use of +offset(%ebp) is not compatible with regcall 
convention", since there is not a trace of 32 bit instructions in the 
code.


Bernd




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Bernd Böckmann via Freedos-devel]

Hello Aitor,

> Could you please post the exact message you got from the compiler?

For something like this "FarPointer(@Buffer)" I get the following error 
message:


"Error: Illegal type conversion: "Pointer" to "FarPointer""

My opinion is that this should be supported by the compiler, because it 
is well defined for the small memory model I am working in.


I looked into the keyb source code and tried to compile it with 
FreePascal. One problematic line is for example:


 PWord ( ptr(m-1,1) )^ := m;    { make it self-parented }

Here, Ptr emits a far pointer, and PWord would cast this to a near 
pointer. FreePascal complains about it.


BUT the following at least gets accepted by the compiler:

    type PFarWord = ^Word; far;

 PFarWord ( ptr(m-1,1) )^ := m;    { make it self-parented }

This converts it to a typed FAR pointer, which than can be de-referenced.

What is more concerning are error messages like:

"Warning: Use of +offset(%ebp) is not compatible with regcall 
convention", since there is not a trace of 32 bit instructions in the code.


Bernd




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Aitor Santamaría via Freedos-devel]

Hello,

Could you please post the exact message you got from the compiler?

I got mysefl problems with such convertions trying to compile FD-KEYB with
FPC, but although I posted for help in the forums, I didn't get anything
really useful and finally gave up.
But I am curious if you get the same error.

There's a compatibility mode that makes you switch between using @ or not
before the procedure address, but in either case I got different compile
time errors that made it unable for me to continue.

Thanks,
Aitor




On Thu, 9 Nov 2023 at 00:52, Rugxulo via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> Hi,
>
> On Wed, Nov 8, 2023 at 2:21 PM Bernd Böckmann via Freedos-devel
>  wrote:
> >
> > the tests I did showed that FreePascal is perfectly capable of producing
> > reasonably small binaries fitting the small memory model, if you do not
> > require the full language feature set (stay away from ObjFpc / Delphi
> > modes). SysUtils and exception handling pulls in a significant amount of
> > code, so you either stick with plain FPC or TP modes or have to live
> > with large memory model.
>
> FPC mode is the default and (I believe) allows function overloading
> and structured return values (with slightly different function pointer
> syntax).
>
> > I am not that interested in Turbo Pascal compatibility, so I can not say
> > anything about it. For me, FreePascal provides some benefits over Turbo
> > Pascal, taking my specific use case into account: e.g. 64-bit arithmetic
> > in 8086 real mode.
>
> I believe int64 was originally from Delphi. (Isn't there also "long
> long" support in OpenWatcom via "-za99"?)
>
> > To the specific problem: I have to provide a FAR pointer to the BIOS as
> > a member of an INT13 device access packet. That pointer shall point to a
> > 512 byte array, for which I get a near pointer via the @ address
> > operator. This near pointer has to be converted to a far pointer.
> > Because this operation is clearly defined for the small memory model, I
> > asked if someone knows that a built-in solution exists. But perhaps this
> > question is better addressed to the FreePascal community. In the
> > meantime, I will use the function from my last mail.
>
> Dunno, directly ask FPC guys MarcoV or NickySn. Sometimes they
> frequent the BTTR Forum too.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Phishing attack - warning!

[Wilhelm Spiegl via Freedos-devel]

Hi Ralf,

yes you are right. I noticed all this before (except the link itself because Android devices use no mouse and the link is not shown in that app). Nevertheless - at the end curiosity won.

And I am not the first one and will not be the last one where this happens.

Since I retired I got at least two phone calls from a "Microsoft technician", several Whats App posts: Hi mum/dad I have a new mobile phone number, some messages

of young ladies, the persons that wants to give me millions of dollars and several other phone attack trials (at least not yet a "shock call from police" that my nephew had an accident and i have to pay money to get him free - this shock call still works fine every day although everyone is warned and bank companies ask their customer when they want a bigger amount of money).

 

I do not know if there were reports in USA that M$ lost one of its main access keys for the whole MS cloud some months ago - and did not really publish this (I am not happy to be forced to use OneDrive etc.)

Big companies are hacked here every day. Etc.  means: I am not alone. Some day they will get you too. There are so many different tricks...

And even if YOU are perfect, others are not. Keep in mind that you have left your email address, paypal account or whatever at douzen of websites,

and some day they can / will be hacked as the admin forgot to run the last updates...

 

Just for info: I checked my Android with 5 different virus scanners, four say: there is nothing, the fifth (VirusTotal) reports that TrendMicro-HouseCall found several of them. One of the four other Virus scanner apps is TrendMicro... So much about this theme.

 

Willi

 
>As for the way how this email is made, well, that is as stated before what makes me wonder on how someone can just click on such a link. "One way link" just doesn't >make any sense in the overall "picture" of the email. So first thing I do before I would even attempt to hover over the link with the mouse, which in my email client will >show me the actual address that link points to. At latest at this point, together with the overall indescriptive  email (not counting the apparently badly copied contents of >an half year old email thread), it should be obvious that this is a phishing attempt.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Error compiling FreeDOS Kernel

[perditionc--- via Freedos-devel]

On Wed, Nov 8, 2023 at 3:21 AM Walter Oesch via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> I want to build the FreeDOS Kernel.
> I use Dosbox in Ubuntu Linux and watcom comiler from FreeDOS, version 1.9.
>
> I changed config.b to use watcom and copied to config.bat, then start with
> buildall.bat.
> The compilation hangs in BOOT/boot.asm:437 Warning Must update constant
> offset (17Bh)...
>
> What did i wrong?
>
> Freundliche Grüsse
> Walter Oesch
>
>
That error means that neither ISFAT12 or ISFAT16 was defined during the
assembly of the boot sector or the boot sector file did not assemble such
that the expected offset to patch by sys is at the same place [either
changes were made, possibly assembled differently, or something else
happened].

You will want to use BUILD.BAT not BUILDALL.BAT as the 1st will build a
kernel as you have configured whereas the second is used to build the
kernel multiple times with different options and compilers. If you have
Ubuntu, it will probably be easier to build directly in Linux as that is
how the CI builds are done on GitHub.  I have never tried building in
DOSBox, but that should not affect the build of the boot sector unless it
is somehow causing build options to not be passed to Nasm.

I will try to replicate this weekend.

Jeremy
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Error compiling FreeDOS Kernel

[Walter Oesch via Freedos-devel]

Hallo

I have downloaded the ZIP from https://github.com/FDOS/kernel, Version 2.43
(2043).

I have nothing changed. Later I want to change some parts.

Ubuntu 22.04.3 LTS

I downloaded the assembler NASM version 0.98.39 compiled on Oct 12 2019
(renamed to nasm.exe and put it in the bin folder of watcom.

DOSBox Version 0.74-3

I use dosbox with the old compiler microsoft MSCV70, every ding worked
fine. And i can execute the produce exe on dosbox, everything worked
flawlessly.

I have not installed UPX. May be leads to an error later?
Nor did i export TERMINFO=/lib/terminfo

Freundliche Grüsse
Walter Oesch

Walter Oesch
Erlenweg 12
3806 Bönigen
www.webdesign-oesch.ch
Tel: 033 822 22 75
Mobile: 076 382 55 58


[image: Mailtrack]

Sender
notified by
Mailtrack

09.11.23,
10:34:21

Am Do., 9. Nov. 2023 um 09:14 Uhr schrieb Rugxulo via Freedos-devel <
freedos-devel@lists.sourceforge.net>:

> Hi,
>
> On Wed, Nov 8, 2023 at 2:21 AM Walter Oesch via Freedos-devel
>  wrote:
> >
> > I want to build the FreeDOS Kernel.
>
> Kernel 2043? Any particular reason to not use the stock build? Did you
> modify anything or add any patches? Just curiosity?
>
> > I use Dosbox in Ubuntu Linux and watcom comiler from FreeDOS, version
> 1.9.
>
> Which version of DOSBox? 0.74-3? Which Ubuntu? 20.04 LTS 64-bit?
>
> OpenWatcom can also run natively atop Linux. The old 1.9 installer had
> a bug where it needed "export TERMINFO=/lib/terminfo" first. You could
> also probably unzip it and manually install. (I assume it has a Linux
> makefile somewhere. It also had a MinGW makefile, IIRC.)
>
> You also need NASM and UPX. (You might need one older [or newer??]
> than 2.16.01.)
>
> > I changed config.b to use watcom and copied to config.bat, then start
> with buildall.bat.
> > The compilation hangs in BOOT/boot.asm:437 Warning Must update constant
> offset (17Bh)...
> >
> > What did i wrong?
>
> I don't know, but I'm not sure DOSBox is recommended (or even
> supported) for this kind of task.
>
> The only times I really rebuilt the kernel were atop FreeDOS itself
> (under QEMU or VirtualBox).
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Error compiling FreeDOS Kernel

[Rugxulo via Freedos-devel]

Hi,

On Wed, Nov 8, 2023 at 2:21 AM Walter Oesch via Freedos-devel
 wrote:
>
> I want to build the FreeDOS Kernel.

Kernel 2043? Any particular reason to not use the stock build? Did you
modify anything or add any patches? Just curiosity?

> I use Dosbox in Ubuntu Linux and watcom comiler from FreeDOS, version 1.9.

Which version of DOSBox? 0.74-3? Which Ubuntu? 20.04 LTS 64-bit?

OpenWatcom can also run natively atop Linux. The old 1.9 installer had
a bug where it needed "export TERMINFO=/lib/terminfo" first. You could
also probably unzip it and manually install. (I assume it has a Linux
makefile somewhere. It also had a MinGW makefile, IIRC.)

You also need NASM and UPX. (You might need one older [or newer??]
than 2.16.01.)

> I changed config.b to use watcom and copied to config.bat, then start with 
> buildall.bat.
> The compilation hangs in BOOT/boot.asm:437 Warning Must update constant 
> offset (17Bh)...
>
> What did i wrong?

I don't know, but I'm not sure DOSBox is recommended (or even
supported) for this kind of task.

The only times I really rebuilt the kernel were atop FreeDOS itself
(under QEMU or VirtualBox).


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel