I write the next code in my program,

   Uses dos;
        var r:registers;
        buffer:array [0..512] of byte;
        i:integer;
    begin
          fillchar(buffer,512,0);
          for i:=0 to 512 do
               begin
                 write(buffer[i])
               end;
          for i:=1 to 200 do
               begin
                    r.ah:=$02;
                    r.dl:=$00;
                    r.dh:=$00;
                    r.ch:=$00;
                    r.cl:=$01;
                    r.al:=$01;
                    r.es:=seg(buffer);
                    r.bx:=ofs(buffer);
                    intr($13,r);
                    write(i)
               end;
          writeln('buffer leido');
          for i:=0 to 512 do
               begin
                     write(buffer[i])
               end;
           readln
end.

the fpc 1.0.4 compile ok.
but I when run the program don't read the sector. I use the unit DOS, the target compile is Win32 and my Operating system is Windows Me.

I compile the program with TP 6.0, and it run ok.
Can you help me?

Att.
Luis Del Aguila

Read the manual, specifically the part that lists the differences between 32-bit systems FPC (and Delphi) and BP/TP.

It is better there than I can explain here.

Best as I can explain it... since fpc is a 32bit compilier when you are using assembler type stuff (eg. registers) you need to use 32bit registers. ax, bx, cx, etc are all 16 bit registers. It is pretty processor independant (meaning it doesn't matter if you have a 286 or a Pentium 20) the processors still understand 16 bit code. BUT since this is a 32 bit compilier it requires that you come out of the 286 days and start using stuff made when the 386 was introduced (32 bit registers). Well, this could make no sense... and if it does... sorry. I am tired. But I hope that helped a little..

- Matt

From:
Date sent: Mon, 04 Mar 2002 14:08:05 EST
Subject: Re: [fpc-pascal]interrupt 13h
To:
Send reply to:

Best as I can explain it... since fpc is a 32bit compilier when you are using assembler type stuff (eg. registers) you need to use 32bit registers. ax, bx, cx, etc are all 16 bit registers. It is pretty

.
.

This isn't quite correct, IMHO. You don't necessarily have to use 32- bit registers if you're trying to call 16-bit BIOS services (which is this case), and nothing else (namely, if you don't try to use 16-bit assembly as well). There's another problem though - some BIOS and DOS functions (including this one) expect to get address of a memory buffer for exchanging larger amounts of data. However, you must make sure this memory buffer is accessible to them (i.e. under the 1 MB boundary - 16-bit real mode functions can't access more memory), and you give them a correct address for the buffer (i.e. the one valid in real mode - the same memory area is addressed in an absolutely different way in 32-bit protected mode environment). Basically, you have to use special DPMI functions (GlobalDosAlloc and GlobalDosFree) for allocating memory within the first MB. You can either use unit Go32 delivered as part of our RTL, or unit DPMI by Thomas Schatzl (this one is packed together with a pretty comprehensive manual for DPMI functions; there should be a link to this unit in the contributions sections on our WWW pages).

Hope this helps

Tomas

Date sent: Wed, 13 Mar 2002 17:55:30 -0300
From: Fernando Lozano
To:
Subject: [fpc-pascal]Calling intr from Windows Send reply to:

Maybe (depending on support of the particular DOS function in your environment, i.e. W95 here) if compiling for GO32v2 target. Absolutely not if compiling for Win32 target.

HTH

Tomas

Hi there,

Running a simple program created for Turbo Pascal which uses some DOS system calls (int 21h) I get from wrong results (invalid system date) to a complete system crash. I am not calling functions that need a memmory buffer, just functions where all arguments and return values come from 8086 registers. Is this suposed to work?

I am using an old snapshot (about august 2001) of 1.0.5 under Windows 95.

[]s, Fernando Lozano

Intr() and its cousin MSDOS() are not implemented under Win32. You need to use the system calls in the DOS and Windows units instead.

- Rich

WHAT????
Is this true??
Well, I suppose I can always use assembler to do this, can't I? Yes, this may not be portable to WinNT, but for my purposes, I don't care.

Aitor

----- Original Message -----

Hi Tomas,

The Win32 API has a call to use DOS and BIOS interrupts. I Thought the DOS unit on these systems should have used this call. So there are two functions (intr and msdos) on the DOS unit for Win32 that do not work at all?

[]s, Fernando Lozano

Hi Rich,

Intr() and its cousin MSDOS() are not implemented under Win32. You need to use the system calls in the DOS and Windows units instead.

I did used the intr function from the DOS unit, using the w32 version of fpc.

[]s, Fernando Lozano

Date sent: Wed, 13 Mar 2002 22:18:20 -0300
From: Fernando Lozano
To:
Subject: Re: [fpc-pascal]Calling intr from Windows Send reply to:

Is there really something like "Win32 API" (I mean a consistent set of interface functions working everywhere, where that API is supposedly supported)? ;-))) I'm no Win32 kean myself, but I'm almost sure there's no function to use DOS and BIOS interrupts under WinNT/2000/XP.
Anyway - Intr and MsDos functions are only present in the Dos unit for Win32 to keep interface parts of the Dos unit identical across supported platforms. They do absolutely nothing, as you can see from that unit's sources. DOS and BIOS calls aren't supported under Win32 (in fact, there's nothing to call on WinNT, since direct access to hardware is forbidden there, and there's no DOS underneath - as opposed to Win9x/ME).

Tomas

The only real method for working with 32bit Windows -- whatever the version -- is the Win32 API. It's huge, and has a tremendous number of functions, so if you can't find what you need in there then you probably don't really need it. :-)

Jim

Hi Tomas,

There's something that is published as "Win32 API". You can download the docs from microsoft.com. :)

I'm no Win32 kean myself, but I'm almost sure there's no function to use DOS and BIOS interrupts under WinNT/2000/XP.

Of course this does not exists on NT (2000 and XP being just NT 5.x). But this exists for Windows 95/98/ME.

Anyway - Intr and MsDos functions are only present in the Dos unit for Win32 to keep interface parts of the Dos unit identical across supported platforms. They do absolutely nothing, as you can see from that unit's sources.

If they do nothing how could they generate crashes on some of my test?

[]s, Fernando Lozano

Perhaps it's because your program expects them to do something, like return a useful value, and proceeds on that assumption?

- Rich

From: "Fernando Lozano"
To:
Subject: Re: [fpc-pascal]Calling intr from Windows Date: Fri, 15 Mar 2002 02:49:12 +0100

This is exactly the point. There is a published (but all the time changing) document "Win32 API". But there's (ever was / ever will be) not a single machine supporting all of the published functions. How can anybody talk about an API here? Anyway, I don't think we should use any "Win32 API" function, that isn't available on some of current target platforms and won't be supported on future ones either, in our RTL.

Tomas

can anybody talk about an API here? Anyway, I don't think we should use any "Win32 API" function, that isn't available on some of current target platforms and won't be supported on future ones either, in our RTL.

I agree, but I also think we shouldn't have any function in the RTL that can silently fail. Either we remove the intr and msdos procedures from the interface of all Dos.pp units (except of that for the go32v2 target), or we put a call to runerror in them (with a unique value that gets added to the docs with the description "unsupported function on the current platform").

Striving to a common interface for all platforms is a nice goal, but if it can't be done, you should not silently fail imho, since that kind of bugs are the hardest to track. The same can be said for mark/release, which also do nothing currently.

Jonas

Subject: Re: [fpc-pascal]Calling intr from Windows To:
Date sent: Sat, 16 Mar 2002 11:04:35 +0100 (CET) From: (Marco van de Voort)
Send reply to:

> Striving to a common interface for all platforms is a nice goal, but > if it can't be done, you should not silently fail imho, since that > kind of bugs are the hardest to track. The same can be said for > mark/release, which also do nothing currently.

I agree with this as well. BTW, there's some directive in Kylix for this kind of stuff (unportable things bound to one platform only), IIRC. Do we support this directive currently? It would be a good place to use it, so users can already see possible problems during compilation.

Tomas

Yup.

That would disallow to compile programms even when the unsupported function isn't essential.

I would vote for that:

{$Warning function not implemented for this platform}

This gives a warning, but doesn't nessesarily break compilation.

Striving to a common interface for all platforms is a nice goal, but if it can't be done, you should not silently fail imho, since that kind of bugs are the hardest to track. The same can be said for mark/release, which also do nothing currently.

agree

Andreas K. Foerster wrote

That would disallow to compile programms even when the unsupported function isn't essential.

I don't see how a call to msdos/intr could be 'non essential' (if they would be, then why are they in te program? :). And even though a program could run for a while calling dummy mark/release procedures, it would eventually consume so much RAM the system would become unusable.

Putting a warning in a source only shows that warning while compiling the source (so you'd only see this warning while compiling the Dos unit). And it's only shown if you've turned warnings on. Calling an unsupported function is an error imho, not a "possible error" (which is what a warning indicates)

Jonas

Okay, THEY are essential.

But I meant functions like Sound, SetVisualPage/GetVisualPage..., where the programs could eventually run without them.

But simply missing sound for example is better than having to look for the problem.

I was only talking about procedures functinos which do nothing at all, not those that aren't fully functional (unless it's not obvious they aren't fully functional). OTOH, for you it may be OK that sound() doesn't take the frequency into account under Win32, but we get regular bugreports about that. Then again, maing it call runerror wouldn't pchange very much about that probably :)

SetVisualPage/GetVisualPage...,

I'm not sure, but I think it's possible for a program to determine whether these are supported for a certain mode, so it could adapt itself at runtime.

where the programs could eventually run without them.

I see your point.

But simply missing sound for example is better than having to look for the problem.

A lot if people will also start looking for a problem if their sound doesn't work correct, so I don't think that's a valid argument.

Jonas

I agree, but I also think we shouldn't have any function in the RTL that can silently fail. Either we remove the intr and msdos procedures from

the

interface of all Dos.pp units (except of that for the go32v2 target), or we put a call to runerror in them (with a unique value that gets added

to

the docs with the description "unsupported function on the current platform"). Striving to a common interface for all platforms is a nice goal, but if

it

can't be done, you should not silently fail imho, since that kind of

bugs

are the hardest to track. The same can be said for mark/release, which also do nothing currently.

I concur as well. When I was using FPC for the first time I got caught by intr when trying to compile win32 apps. An outright failure to compile might not be necessary, but certainly a warning should be issued.

Jim

It was just an example!
Perhaps not a good one.

But it was you, who wrote: "we shouldn't have any function in the RTL that can silently fail" and you suggested to let them produce a runerror.
All I wanted to say is, that there are empty functions, which are not so essential - there it would do more harm, when they produce a runerror. They /should/ just "fail" - but please not "silently".

> where the programs could eventually run without them. I see your point.

really?

But then they have at least a running program.

Okay, stripped down, what I wanted to say is:
1. don't implement unneccessary runerrors
2. give warnings instead

PM Jonas Maebe wrote

OTOH, for you it may be OK that sound() doesn't take the frequency into account under Win32, but we get regular bugreports about that.

Why doesn't Sound work? Under Win32 the Kernal32 function Beep does it.

function Beep(dwFreq, dwDuration: DWORD): BOOL; stdcall;
function Beep; external kernel32 name 'Beep';

Works in XP, at least.

Jeff.

Jeff Wormsley wrote

Why doesn't Sound work? Under Win32 the Kernal32 function Beep does it. function Beep(dwFreq, dwDuration: DWORD): BOOL; stdcall; function Beep; external kernel32 name 'Beep';

I think the problem is that the kernel function Beep needs a second parameter giving the duration, whereas Sound runs until a subsequent NoSound comes along. So it would be hard to implement Sound and NoSound as calls to Beep.

My work-around in my source code is to use {$ifdef win32} Beep() ...
{$else} Sound() ... NoSound; {$endif}.
     - Rich

Date sent: Sun, 17 Mar 2002 22:13:10 +0100 (CET) From: Jonas Maebe
To:
Subject: Re: [fpc-pascal]Calling intr from Windows Send reply to:

Another possibility just coming to my mind would be to just set the CY flag (in the record of registers) in all calls to MsDos / Intr (this is returned as an error in most - if not all - DOS / BIOS functions).

Tomas