The following program when compiled for the 8088 cpu and executed on intel 8088 CPU froze on the fscanf line so it never run printf("d\n"). I executed the 8088 exe program without recompilation under 286, 386 and up and it ran perfectly. I attached the input file read by this program, it's a simple liste of numbers.

Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
same result without -o OR
with -ms instead of -ml OR
with -mld OR with or without -a2

#include <stdio.h>

int main(int argc, char **argv) {
FILE *stream;
unsigned Version;

printf("a\n");
stream = fopen( "xor.asc", "r" );
printf("b\n");
if ( stream != NULL ) {
printf("c\n");
fscanf( stream, "%u", &Version );
printf("d\n");
}
printf("e\n");
fclose( stream );
printf("f\n");

return 0;
}

I very happy about the compiler because it's the only one I found that was able to compile my personnal 6500lines C++ project for any CPU below 386 that understand very well C++ templates using each other in deadlock situation.

I also found that double division like: (double)(clock_t_var_a - clock_t_var_b) / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on 286 cpu and up without recompilation... work fine on 8088 only if I remove (/ CLOCKS_PER_SEC) and just display the two clock_t value and do the divide in my head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile! Compilation parameters are the same as above except that I also tested the 3 floating point parameters(-f -ff -fd) withtout success...

I have two XT computers, one without a 8087 coprocessor and one with it but the divide operant froze on both... The XT computer with a 8087 is not having a intel 8088 but a V20cpu and curiously that one is not having problem with fscanf! I also tested reading over floppy without success, I also tested 8088 XT with the xt v20 hardrive without success...

any idea? maybe something with the dos libraries with the 8088...

thanks...

Benoit

    Seems that the fscanf function in the library is using some kind of
186/V20 or later CPU instruction, such as SHL or SHR with an inmediate
greater than 1 or so.

    Maybe Walter could fix it.


"Benoit" <Benoit_member@pathlink.com> escribió en el mensaje news:b4nl3s$1r1v$1@digitaldaemon.com...
> The following program when compiled for the 8088 cpu and executed on intel
8088
> CPU froze on the fscanf line so it never run printf("d\n"). I executed the
8088
> exe program without recompilation under 286, 386 and up and it ran
perfectly. I
> attached the input file read by this program, it's a simple liste of
numbers.
>
> Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
> same result without -o OR
> with -ms instead of -ml OR
> with -mld OR with or without -a2
>
> #include <stdio.h>
>
> int main(int argc, char **argv) {
> FILE *stream;
> unsigned Version;
>
> printf("a\n");
> stream = fopen( "xor.asc", "r" );
> printf("b\n");
> if ( stream != NULL ) {
> printf("c\n");
> fscanf( stream, "%u", &Version );
> printf("d\n");
> }
> printf("e\n");
> fclose( stream );
> printf("f\n");
>
> return 0;
> }
>
> I very happy about the compiler because it's the only one I found that was
able
> to compile my personnal 6500lines C++ project for any CPU below 386 that understand very well C++ templates using each other in deadlock situation.
>
> I also found that double division like: (double)(clock_t_var_a -
clock_t_var_b)
> / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on
286 cpu
> and up without recompilation... work fine on 8088 only if I remove (/ CLOCKS_PER_SEC) and just display the two clock_t value and do the divide
in my
> head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile! Compilation parameters are the same as above except that I also tested the
3
> floating point parameters(-f -ff -fd) withtout success...
>
> I have two XT computers, one without a 8087 coprocessor and one with it
but the
> divide operant froze on both... The XT computer with a 8087 is not having
a
> intel 8088 but a V20cpu and curiously that one is not having problem with fscanf! I also tested reading over floppy without success, I also tested
8088 XT
> with the xt v20 hardrive without success...
>
> any idea? maybe something with the dos libraries with the 8088...
>
> thanks...
>
> Benoit
>
>
>

I noticed (DMC 8.23) that asm bswap; compiles even in <=386 cpu as asm cpuid; or asm rdtsc; on <= 486 cpu.
It is not correct.
One could think the <Pentium market is so small that the simplest way of fixing all that is to remove <Pentium cpu compilation.
May be wrong: <Pentium cpu can still exist on embeded systems and pc's on a chip. precisely some area where DOS is good.

roland

Javier Gutiérrez wrote:

>     Seems that the fscanf function in the library is using some kind of
> 186/V20 or later CPU instruction, such as SHL or SHR with an inmediate
> greater than 1 or so.
> 
>     Maybe Walter could fix it.
> 
> 
> "Benoit" <Benoit_member@pathlink.com> escribió en el mensaje
> news:b4nl3s$1r1v$1@digitaldaemon.com...
> 
>>The following program when compiled for the 8088 cpu and executed on intel
>>
> 8088
> 
>>CPU froze on the fscanf line so it never run printf("d\n"). I executed the
>>
> 8088
> 
>>exe program without recompilation under 286, 386 and up and it ran
>>
> perfectly. I
> 
>>attached the input file read by this program, it's a simple liste of
>>
> numbers.
> 
>>Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
>>same result without -o OR
>>with -ms instead of -ml OR
>>with -mld OR with or without -a2
>>
>>#include <stdio.h>
>>
>>int main(int argc, char **argv) {
>>FILE *stream;
>>unsigned Version;
>>
>>printf("a\n");
>>stream = fopen( "xor.asc", "r" );
>>printf("b\n");
>>if ( stream != NULL ) {
>>printf("c\n");
>>fscanf( stream, "%u", &Version );
>>printf("d\n");
>>}
>>printf("e\n");
>>fclose( stream );
>>printf("f\n");
>>
>>return 0;
>>}
>>
>>I very happy about the compiler because it's the only one I found that was
>>
> able
> 
>>to compile my personnal 6500lines C++ project for any CPU below 386 that
>>understand very well C++ templates using each other in deadlock situation.
>>
>>I also found that double division like: (double)(clock_t_var_a -
>>
> clock_t_var_b)
> 
>>/ CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on
>>
> 286 cpu
> 
>>and up without recompilation... work fine on 8088 only if I remove (/
>>CLOCKS_PER_SEC) and just display the two clock_t value and do the divide
>>
> in my
> 
>>head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile!
>>Compilation parameters are the same as above except that I also tested the
>>
> 3
> 
>>floating point parameters(-f -ff -fd) withtout success...
>>
>>I have two XT computers, one without a 8087 coprocessor and one with it
>>
> but the
> 
>>divide operant froze on both... The XT computer with a 8087 is not having
>>
> a
> 
>>intel 8088 but a V20cpu and curiously that one is not having problem with
>>fscanf! I also tested reading over floppy without success, I also tested
>>
> 8088 XT
> 
>>with the xt v20 hardrive without success...
>>
>>any idea? maybe something with the dos libraries with the 8088...
>>
>>thanks...
>>
>>Benoit
>>
>>
>>
>>
> 
> 

I have a little more that might help Walter, if I comment the fscanf line in my test program, the exe froze on the fclose instruction instead. Weird! I found that one after having coded a routine to replace fscanf by a simple one reading numbers using fgetc. My routine worked fine (so fgetc work) but I was so surprise to see the test program froze on fclose. My previous last chance is to code with unbuffered lower lever instructions like open, read, write, close.. will see later. My last chance will be to make a personnal lib of files IO functions(I dont need a lot) compiled using another C compiler and link that lib with the near perfect Digital Mars compiler, but for now, I dont know which other old C compiler to choose to make a lib linkable with Digital Mars compiler?

Yes, maybe there are some invalid cpu instructions inside libs for the 8088.

Benoit

In article <b4npl3$1uq8$1@digitaldaemon.com>, Javier Gutiérrez says...
>
>    Seems that the fscanf function in the library is using some kind of
>186/V20 or later CPU instruction, such as SHL or SHR with an inmediate greater than 1 or so.
>
>    Maybe Walter could fix it.
>
>
>"Benoit" <Benoit_member@pathlink.com> escribió en el mensaje news:b4nl3s$1r1v$1@digitaldaemon.com...
>> The following program when compiled for the 8088 cpu and executed on intel
>8088
>> CPU froze on the fscanf line so it never run printf("d\n"). I executed the
>8088
>> exe program without recompilation under 286, 386 and up and it ran
>perfectly. I
>> attached the input file read by this program, it's a simple liste of
>numbers.
>>
>> Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
>> same result without -o OR
>> with -ms instead of -ml OR
>> with -mld OR with or without -a2
>>
>> #include <stdio.h>
>>
>> int main(int argc, char **argv) {
>> FILE *stream;
>> unsigned Version;
>>
>> printf("a\n");
>> stream = fopen( "xor.asc", "r" );
>> printf("b\n");
>> if ( stream != NULL ) {
>> printf("c\n");
>> fscanf( stream, "%u", &Version );
>> printf("d\n");
>> }
>> printf("e\n");
>> fclose( stream );
>> printf("f\n");
>>
>> return 0;
>> }
>>
>> I very happy about the compiler because it's the only one I found that was
>able
>> to compile my personnal 6500lines C++ project for any CPU below 386 that understand very well C++ templates using each other in deadlock situation.
>>
>> I also found that double division like: (double)(clock_t_var_a -
>clock_t_var_b)
>> / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on
>286 cpu
>> and up without recompilation... work fine on 8088 only if I remove (/ CLOCKS_PER_SEC) and just display the two clock_t value and do the divide
>in my
>> head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile! Compilation parameters are the same as above except that I also tested the
>3
>> floating point parameters(-f -ff -fd) withtout success...
>>
>> I have two XT computers, one without a 8087 coprocessor and one with it
>but the
>> divide operant froze on both... The XT computer with a 8087 is not having
>a
>> intel 8088 but a V20cpu and curiously that one is not having problem with fscanf! I also tested reading over floppy without success, I also tested
>8088 XT
>> with the xt v20 hardrive without success...
>>
>> any idea? maybe something with the dos libraries with the 8088...
>>
>> thanks...
>>
>> Benoit
>>
>>
>>
>
>

It's probably generating an instruction not found on the 8088. I'll take a look for it.

"Benoit" <Benoit_member@pathlink.com> wrote in message news:b4nl3s$1r1v$1@digitaldaemon.com...
> The following program when compiled for the 8088 cpu and executed on intel
8088
> CPU froze on the fscanf line so it never run printf("d\n"). I executed the
8088
> exe program without recompilation under 286, 386 and up and it ran
perfectly. I
> attached the input file read by this program, it's a simple liste of
numbers.
>
> Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
> same result without -o OR
> with -ms instead of -ml OR
> with -mld OR with or without -a2
>
> #include <stdio.h>
>
> int main(int argc, char **argv) {
> FILE *stream;
> unsigned Version;
>
> printf("a\n");
> stream = fopen( "xor.asc", "r" );
> printf("b\n");
> if ( stream != NULL ) {
> printf("c\n");
> fscanf( stream, "%u", &Version );
> printf("d\n");
> }
> printf("e\n");
> fclose( stream );
> printf("f\n");
>
> return 0;
> }
>
> I very happy about the compiler because it's the only one I found that was
able
> to compile my personnal 6500lines C++ project for any CPU below 386 that understand very well C++ templates using each other in deadlock situation.
>
> I also found that double division like: (double)(clock_t_var_a -
clock_t_var_b)
> / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on
286 cpu
> and up without recompilation... work fine on 8088 only if I remove (/ CLOCKS_PER_SEC) and just display the two clock_t value and do the divide
in my
> head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile! Compilation parameters are the same as above except that I also tested the
3
> floating point parameters(-f -ff -fd) withtout success...
>
> I have two XT computers, one without a 8087 coprocessor and one with it
but the
> divide operant froze on both... The XT computer with a 8087 is not having
a
> intel 8088 but a V20cpu and curiously that one is not having problem with fscanf! I also tested reading over floppy without success, I also tested
8088 XT
> with the xt v20 hardrive without success...
>
> any idea? maybe something with the dos libraries with the 8088...
>
> thanks...
>
> Benoit
>
>
>

Hmm - any way for you to load a debugger and see which instruction it is failing on?

"Benoit" <Benoit_member@pathlink.com> wrote in message news:b4nl3s$1r1v$1@digitaldaemon.com...
> The following program when compiled for the 8088 cpu and executed on intel
8088
> CPU froze on the fscanf line so it never run printf("d\n"). I executed the
8088
> exe program without recompilation under 286, 386 and up and it ran
perfectly. I
> attached the input file read by this program, it's a simple liste of
numbers.
>
> Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
> same result without -o OR
> with -ms instead of -ml OR
> with -mld OR with or without -a2
>
> #include <stdio.h>
>
> int main(int argc, char **argv) {
> FILE *stream;
> unsigned Version;
>
> printf("a\n");
> stream = fopen( "xor.asc", "r" );
> printf("b\n");
> if ( stream != NULL ) {
> printf("c\n");
> fscanf( stream, "%u", &Version );
> printf("d\n");
> }
> printf("e\n");
> fclose( stream );
> printf("f\n");
>
> return 0;
> }
>
> I very happy about the compiler because it's the only one I found that was
able
> to compile my personnal 6500lines C++ project for any CPU below 386 that understand very well C++ templates using each other in deadlock situation.
>
> I also found that double division like: (double)(clock_t_var_a -
clock_t_var_b)
> / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on
286 cpu
> and up without recompilation... work fine on 8088 only if I remove (/ CLOCKS_PER_SEC) and just display the two clock_t value and do the divide
in my
> head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile! Compilation parameters are the same as above except that I also tested the
3
> floating point parameters(-f -ff -fd) withtout success...
>
> I have two XT computers, one without a 8087 coprocessor and one with it
but the
> divide operant froze on both... The XT computer with a 8087 is not having
a
> intel 8088 but a V20cpu and curiously that one is not having problem with fscanf! I also tested reading over floppy without success, I also tested
8088 XT
> with the xt v20 hardrive without success...
>
> any idea? maybe something with the dos libraries with the 8088...
>
> thanks...
>
> Benoit
>
>
>

I went look at the adress of the CALL and MAYBE I found some instuctions that are not part of the 41 instructions SET of th 8088.

C45E0A         LES   BX,[BP+0A]
99             CWD
26             ES:
98             CBW
CA0C00         RETF 000C

Benoit

In article <b4olfb$2mvq$1@digitaldaemon.com>, Walter says...
>
>Hmm - any way for you to load a debugger and see which instruction it is failing on?
>
>"Benoit" <Benoit_member@pathlink.com> wrote in message news:b4nl3s$1r1v$1@digitaldaemon.com...
>> The following program when compiled for the 8088 cpu and executed on intel
>8088
>> CPU froze on the fscanf line so it never run printf("d\n"). I executed the
>8088
>> exe program without recompilation under 286, 386 and up and it ran
>perfectly. I
>> attached the input file read by this program, it's a simple liste of
>numbers.
>>
>> Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
>> same result without -o OR
>> with -ms instead of -ml OR
>> with -mld OR with or without -a2
>>
>> #include <stdio.h>
>>
>> int main(int argc, char **argv) {
>> FILE *stream;
>> unsigned Version;
>>
>> printf("a\n");
>> stream = fopen( "xor.asc", "r" );
>> printf("b\n");
>> if ( stream != NULL ) {
>> printf("c\n");
>> fscanf( stream, "%u", &Version );
>> printf("d\n");
>> }
>> printf("e\n");
>> fclose( stream );
>> printf("f\n");
>>
>> return 0;
>> }
>>
>> I very happy about the compiler because it's the only one I found that was
>able
>> to compile my personnal 6500lines C++ project for any CPU below 386 that understand very well C++ templates using each other in deadlock situation.
>>
>> I also found that double division like: (double)(clock_t_var_a -
>clock_t_var_b)
>> / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on
>286 cpu
>> and up without recompilation... work fine on 8088 only if I remove (/ CLOCKS_PER_SEC) and just display the two clock_t value and do the divide
>in my
>> head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile! Compilation parameters are the same as above except that I also tested the
>3
>> floating point parameters(-f -ff -fd) withtout success...
>>
>> I have two XT computers, one without a 8087 coprocessor and one with it
>but the
>> divide operant froze on both... The XT computer with a 8087 is not having
>a
>> intel 8088 but a V20cpu and curiously that one is not having problem with fscanf! I also tested reading over floppy without success, I also tested
>8088 XT
>> with the xt v20 hardrive without success...
>>
>> any idea? maybe something with the dos libraries with the 8088...
>>
>> thanks...
>>
>> Benoit
>>
>>
>>
>
>

I don's see -0 switch in your command line. I think 8086 is not default any more.

Nic Tiger.

"Benoit" <Benoit_member@pathlink.com> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:b4nl3s$1r1v$1@digitaldaemon.com...
> The following program when compiled for the 8088 cpu and executed on intel
8088
> CPU froze on the fscanf line so it never run printf("d\n"). I executed the
8088
> exe program without recompilation under 286, 386 and up and it ran
perfectly. I
> attached the input file read by this program, it's a simple liste of
numbers.
>
> Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
> same result without -o OR
> with -ms instead of -ml OR
> with -mld OR with or without -a2
>
> #include <stdio.h>
>
> int main(int argc, char **argv) {
> FILE *stream;
> unsigned Version;
>
> printf("a\n");
> stream = fopen( "xor.asc", "r" );
> printf("b\n");
> if ( stream != NULL ) {
> printf("c\n");
> fscanf( stream, "%u", &Version );
> printf("d\n");
> }
> printf("e\n");
> fclose( stream );
> printf("f\n");
>
> return 0;
> }
>
> I very happy about the compiler because it's the only one I found that was
able
> to compile my personnal 6500lines C++ project for any CPU below 386 that understand very well C++ templates using each other in deadlock situation.
>
> I also found that double division like: (double)(clock_t_var_a -
clock_t_var_b)
> / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on
286 cpu
> and up without recompilation... work fine on 8088 only if I remove (/ CLOCKS_PER_SEC) and just display the two clock_t value and do the divide
in my
> head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile! Compilation parameters are the same as above except that I also tested the
3
> floating point parameters(-f -ff -fd) withtout success...
>
> I have two XT computers, one without a 8087 coprocessor and one with it
but the
> divide operant froze on both... The XT computer with a 8087 is not having
a
> intel 8088 but a V20cpu and curiously that one is not having problem with fscanf! I also tested reading over floppy without success, I also tested
8088 XT
> with the xt v20 hardrive without success...
>
> any idea? maybe something with the dos libraries with the 8088...
>
> thanks...
>
> Benoit
>
>
>

Those are valid 8088 instructions. Look for maybe a shl or shr?

"Benoit" <Benoit_member@pathlink.com> wrote in message news:b4p0cn$2ufs$1@digitaldaemon.com...
> I went look at the adress of the CALL and MAYBE I found some instuctions
that
> are not part of the 41 instructions SET of th 8088.
>
> C45E0A         LES   BX,[BP+0A]
> 99             CWD
> 26             ES:
> 98             CBW
> CA0C00         RETF 000C
>
> Benoit
>
> In article <b4olfb$2mvq$1@digitaldaemon.com>, Walter says...
> >
> >Hmm - any way for you to load a debugger and see which instruction it is failing on?
> >
> >"Benoit" <Benoit_member@pathlink.com> wrote in message news:b4nl3s$1r1v$1@digitaldaemon.com...
> >> The following program when compiled for the 8088 cpu and executed on
intel
> >8088
> >> CPU froze on the fscanf line so it never run printf("d\n"). I executed
the
> >8088
> >> exe program without recompilation under 286, 386 and up and it ran
> >perfectly. I
> >> attached the input file read by this program, it's a simple liste of
> >numbers.
> >>
> >> Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
> >> same result without -o OR
> >> with -ms instead of -ml OR
> >> with -mld OR with or without -a2
> >>
> >> #include <stdio.h>
> >>
> >> int main(int argc, char **argv) {
> >> FILE *stream;
> >> unsigned Version;
> >>
> >> printf("a\n");
> >> stream = fopen( "xor.asc", "r" );
> >> printf("b\n");
> >> if ( stream != NULL ) {
> >> printf("c\n");
> >> fscanf( stream, "%u", &Version );
> >> printf("d\n");
> >> }
> >> printf("e\n");
> >> fclose( stream );
> >> printf("f\n");
> >>
> >> return 0;
> >> }
> >>
> >> I very happy about the compiler because it's the only one I found that
was
> >able
> >> to compile my personnal 6500lines C++ project for any CPU below 386
that
> >> understand very well C++ templates using each other in deadlock
situation.
> >>
> >> I also found that double division like: (double)(clock_t_var_a -
> >clock_t_var_b)
> >> / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on
> >286 cpu
> >> and up without recompilation... work fine on 8088 only if I remove (/ CLOCKS_PER_SEC) and just display the two clock_t value and do the
divide
> >in my
> >> head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000.
smile!
> >> Compilation parameters are the same as above except that I also tested
the
> >3
> >> floating point parameters(-f -ff -fd) withtout success...
> >>
> >> I have two XT computers, one without a 8087 coprocessor and one with it
> >but the
> >> divide operant froze on both... The XT computer with a 8087 is not
having
> >a
> >> intel 8088 but a V20cpu and curiously that one is not having problem
with
> >> fscanf! I also tested reading over floppy without success, I also
tested
> >8088 XT
> >> with the xt v20 hardrive without success...
> >>
> >> any idea? maybe something with the dos libraries with the 8088...
> >>
> >> thanks...
> >>
> >> Benoit
> >>
> >>
> >>
> >
> >
>
>

    It is there: dmc -o -ml -0 tst02.cpp -otst02.exe


"Nic Tiger" <nictiger@progtech.ru> escribió en el mensaje news:b4p2g9$2vr1$1@digitaldaemon.com...
> I don's see -0 switch in your command line. I think 8086 is not default
any
> more.
>
> Nic Tiger.
>
> "Benoit" <Benoit_member@pathlink.com> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ
ÓÌÅÄÕÀÝÅÅ:
> news:b4nl3s$1r1v$1@digitaldaemon.com...
> > The following program when compiled for the 8088 cpu and executed on
intel
> 8088
> > CPU froze on the fscanf line so it never run printf("d\n"). I executed
the
> 8088
> > exe program without recompilation under 286, 386 and up and it ran
> perfectly. I
> > attached the input file read by this program, it's a simple liste of
> numbers.
> >
> > Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
> > same result without -o OR
> > with -ms instead of -ml OR
> > with -mld OR with or without -a2
> >
> > #include <stdio.h>
> >
> > int main(int argc, char **argv) {
> > FILE *stream;
> > unsigned Version;
> >
> > printf("a\n");
> > stream = fopen( "xor.asc", "r" );
> > printf("b\n");
> > if ( stream != NULL ) {
> > printf("c\n");
> > fscanf( stream, "%u", &Version );
> > printf("d\n");
> > }
> > printf("e\n");
> > fclose( stream );
> > printf("f\n");
> >
> > return 0;
> > }
> >
> > I very happy about the compiler because it's the only one I found that
was
> able
> > to compile my personnal 6500lines C++ project for any CPU below 386 that understand very well C++ templates using each other in deadlock
situation.
> >
> > I also found that double division like: (double)(clock_t_var_a -
> clock_t_var_b)
> > / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on
> 286 cpu
> > and up without recompilation... work fine on 8088 only if I remove (/ CLOCKS_PER_SEC) and just display the two clock_t value and do the divide
> in my
> > head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000.
smile!
> > Compilation parameters are the same as above except that I also tested
the
> 3
> > floating point parameters(-f -ff -fd) withtout success...
> >
> > I have two XT computers, one without a 8087 coprocessor and one with it
> but the
> > divide operant froze on both... The XT computer with a 8087 is not
having
> a
> > intel 8088 but a V20cpu and curiously that one is not having problem
with
> > fscanf! I also tested reading over floppy without success, I also tested
> 8088 XT
> > with the xt v20 hardrive without success...
> >
> > any idea? maybe something with the dos libraries with the 8088...
> >
> > thanks...
> >
> > Benoit
> >
> >
> >
>
>