f



Random compile errors under WIndows (32 bit Windows Vista and Windows 10)

I have earlier noticed random stray compile errors when building
DJGPP port of gcc under Windows Vista Business. Running make again
compiled some file without problems. Such errors where
extremely rare for DJGPP CVS from CVS (also 2.04 before bumping version
to 2.05). I usually did not get them at all for 2.04 or 2.05. The situation
was noticeably worse for 2.03p2. Building GCC was still possible but I had to
restart build often enough.

I have 64-bit Windows 10 (earlier Windows 7) on desktop computer and dual boot
with Linux (currently Fedora 22 x86_64). So there no DJGPP testing possible in this
Windows installation for understandable reasons.

Today downloaded 32 bit Windows 10 Enterprise 90 days trial from Microsoft and
installed it in VirtualBox VM under Linux. I needed slightly more steps to get DJGPP
working rather than on Windows Vista (for VIsta only registry hack was needed to
workaround 32MB DMPI memory limit)

Trying to build gcc-5.2.0 on this Windows 10 installation (DJGPP v2.05 only) showed
that I'm getting stray compiler errors much more often (once per several minutes)

These errors look like:
gpp -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Ic-family -I/gcc-5.20/gcc 
-I/gcc-5.20/gcc/c-family -I/gcc-5.20/gcc/../include -I/gcc-5.20/gcc/../libcpp/include  
-I/gcc-5.20/gcc/../libdecnumber -I/gcc-5.20/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/gcc-5.20/gcc/../libbacktrace  -I/dev/env/DJDIR/include -o c-family/c-gimplify.o -MT 
c-family/c-gimplify.o -MMD -MP -MF c-family/.deps/c-gimplify.TPo /gcc-5.20/gcc/c-family/c-gimplify.c
In file included from /gcc-5.20/gcc/flags.h:24:0,
                  from /gcc-5.20/gcc/c-family/c-common.h:36,
                  from /gcc-5.20/gcc/c-family/c-gimplify.c:41:
./options.h:10:0: error: unterminated #if
  #if !defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) && !defined(IN_RTS)
  ^
./options.h:3:0: error: unterminated #ifndef
  #ifndef OPTIONS_H
  ^
Makefile:1066: recipe for target 'c-family/c-gimplify.o' failed
make.exe[3]: *** [c-family/c-gimplify.o] Error 1
make.exe[3]: Leaving directory 'c:/build.gcc/gcc'
Makefile:4376: recipe for target 'all-stage1-gcc' failed
make.exe[2]: *** [all-stage1-gcc] Error 2
make.exe[2]: Leaving directory 'c:/build.gcc'
Makefile:17534: recipe for target 'stage1-bubble' failed
make.exe[1]: *** [stage1-bubble] Error 2
make.exe[1]: Leaving directory 'c:/build.gcc'
Makefile:17838: recipe for target 'bootstrap' failed
make.exe: *** [bootstrap] Error 2

Same error do not repeat when I try to run 'sh ./djmake.sh bootstrap' again.

Most likely explanation is that reading file (opened in binary mode) is unreliable
and one randomly gets corrupted data. Total data size is correct as libcpp compares
data size with one from response of stat() and reports an error in case of size discrepancy
(we needed to handle DOS end of file mark ^Z specially for that reason)

It could be a bug in NTVDM. It could also be some problem on our side.
More testing is needed. Such test could repeatedly read some set of files into memory
and calculate MD5 sum or something similar to detect random corruptions. It would
be possible to investigate further and see what is getting corrupted


How to get DJGPP programs running on Windows 10 32 bit (please comment
if one has possibility to check on different edition)

Steps needed to get DJGPP apps running on 32 bit WIndows 10 enterprise trial version.
It may be different in Win 10 Home or WIn 10 Pro. I just do not know.

1) Dialog asking confirmation for installing NTVDM appears when trying
to run DJGPP program first time: You need to allow it to be run any DJGPP
executable (it was when I tried to run unzip32.exe)

2) 32 MB DPMI memory limit is still present. Use old hack from Windows Vista
epoch to got around it: Add registry entry DpmiLimit with large enough
value to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW.
No need to restart Windows. It's active immediately.
I used value 0x7FFFFFFF and it is accepted and works

3) Command prompt configuration: mark check box "Use legacy console" active.
Otherwise ls.exe, bash.exe, less.exe and other similar programs will not work and Windows
will report NTVDM error

Andris

0
Andris
10/4/2015 4:40:12 PM
comp.os.msdos.djgpp 3308 articles. 2 followers. tigrepotrazosalvaje (34) is leader. Post Follow

28 Replies
870 Views

Similar Articles

[PageSpeed] 55

On 10/04/2015 07:40 PM, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
> I have earlier noticed random stray compile errors when building
> DJGPP port of gcc under Windows Vista Business. Running make again
> compiled some file without problems. Such errors where
> extremely rare for DJGPP CVS from CVS (also 2.04 before bumping version
> to 2.05). I usually did not get them at all for 2.04 or 2.05. The situation
> was noticeably worse for 2.03p2. Building GCC was still possible but I had to
> restart build often enough.
>
> I have 64-bit Windows 10 (earlier Windows 7) on desktop computer and dual boot
> with Linux (currently Fedora 22 x86_64). So there no DJGPP testing possible in this
> Windows installation for understandable reasons.
>
> Today downloaded 32 bit Windows 10 Enterprise 90 days trial from Microsoft and
> installed it in VirtualBox VM under Linux. I needed slightly more steps to get DJGPP
> working rather than on Windows Vista (for VIsta only registry hack was needed to
> workaround 32MB DMPI memory limit)
>
> Trying to build gcc-5.2.0 on this Windows 10 installation (DJGPP v2.05 only) showed
> that I'm getting stray compiler errors much more often (once per several minutes)
>
> These errors look like:
> gpp -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti 
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Ic-family -I/gcc-5.20/gcc 
> -I/gcc-5.20/gcc/c-family -I/gcc-5.20/gcc/../include -I/gcc-5.20/gcc/../libcpp/include  
> -I/gcc-5.20/gcc/../libdecnumber -I/gcc-5.20/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I/gcc-5.20/gcc/../libbacktrace  -I/dev/env/DJDIR/include -o c-family/c-gimplify.o -MT 
> c-family/c-gimplify.o -MMD -MP -MF c-family/.deps/c-gimplify.TPo /gcc-5.20/gcc/c-family/c-gimplify.c
> In file included from /gcc-5.20/gcc/flags.h:24:0,
>                  from /gcc-5.20/gcc/c-family/c-common.h:36,
>                  from /gcc-5.20/gcc/c-family/c-gimplify.c:41:
> ./options.h:10:0: error: unterminated #if
>  #if !defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) && !defined(IN_RTS)
>  ^
> ./options.h:3:0: error: unterminated #ifndef
>  #ifndef OPTIONS_H
>  ^
> Makefile:1066: recipe for target 'c-family/c-gimplify.o' failed
> make.exe[3]: *** [c-family/c-gimplify.o] Error 1
> make.exe[3]: Leaving directory 'c:/build.gcc/gcc'
> Makefile:4376: recipe for target 'all-stage1-gcc' failed
> make.exe[2]: *** [all-stage1-gcc] Error 2
> make.exe[2]: Leaving directory 'c:/build.gcc'
> Makefile:17534: recipe for target 'stage1-bubble' failed
> make.exe[1]: *** [stage1-bubble] Error 2
> make.exe[1]: Leaving directory 'c:/build.gcc'
> Makefile:17838: recipe for target 'bootstrap' failed
> make.exe: *** [bootstrap] Error 2
>
> Same error do not repeat when I try to run 'sh ./djmake.sh bootstrap' again.
>
> Most likely explanation is that reading file (opened in binary mode) is unreliable
> and one randomly gets corrupted data. Total data size is correct as libcpp compares
> data size with one from response of stat() and reports an error in case of size discrepancy
> (we needed to handle DOS end of file mark ^Z specially for that reason)
>
> It could be a bug in NTVDM. It could also be some problem on our side.
> More testing is needed. Such test could repeatedly read some set of files into memory
> and calculate MD5 sum or something similar to detect random corruptions. It would
> be possible to investigate further and see what is getting corrupted
>
>
> How to get DJGPP programs running on Windows 10 32 bit (please comment
> if one has possibility to check on different edition)

On of suspect is change to nmalloc. I have used it for a long time for GCC and there has been
some instability related to it on Windows (different versions).

My ancient test program written to test perfomance of memory allocation/freeing

http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2007/12/05/17:54:46

also randomly crashed on Windows when linked with nmalloc. I did not found them why it happens.
Also WIndows 10 is not an exception as I have found in my test VM (Windows 10 Enterprise trial)

Changed only one thing (added int _crt0_startup_flags = _CRT0_DISABLE_SBRK_ADDRESS_WRAP;

And it seems to help in case of Windows 10 as the test program has run for several hours more
than 2000 times without any crash (command line parameter value 20000000). Rebuild of
gcc-5.2.0 with this flag set is ongoing on another system, so I'll be able to see whether it fixes 
the problem.

Also: trying to set _CRT0_FLAG_UNIX_SBRK caused test program to crash immediately on Windows 10.
I have not tried to investigate it further yet.

Andris

0
Andris
10/11/2015 11:45:18 AM
Am 11.10.2015 13:45, schrieb Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com]:
> On 10/04/2015 07:40 PM, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
>> I have earlier noticed random stray compile errors when building
>> DJGPP port of gcc under Windows Vista Business. Running make again
>> compiled some file without problems. Such errors where
>> extremely rare for DJGPP CVS from CVS (also 2.04 before bumping version
>> to 2.05). I usually did not get them at all for 2.04 or 2.05. The situation
>> was noticeably worse for 2.03p2. Building GCC was still possible but I had to
>> restart build often enough.
>>
>> I have 64-bit Windows 10 (earlier Windows 7) on desktop computer and dual boot
>> with Linux (currently Fedora 22 x86_64). So there no DJGPP testing possible in this
>> Windows installation for understandable reasons.
>>
>> Today downloaded 32 bit Windows 10 Enterprise 90 days trial from Microsoft and
>> installed it in VirtualBox VM under Linux. I needed slightly more steps to get DJGPP
>> working rather than on Windows Vista (for VIsta only registry hack was needed to
>> workaround 32MB DMPI memory limit)
>>
>> Trying to build gcc-5.2.0 on this Windows 10 installation (DJGPP v2.05 only) showed
>> that I'm getting stray compiler errors much more often (once per several minutes)
>>
>> These errors look like:
>> gpp -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I/gcc-5.20/gcc -I/gcc-5.20/gcc/c-family -I/gcc-5.20/gcc/../include -I/gcc-5.20/gcc/../libcpp/include -I/gcc-5.20/gcc/../libdecnumber -I/gcc-5.20/gcc/../libdecnumber/dpd -I../libdecnumber -I/gcc-5.20/gcc/../libbacktrace -I/dev/env/DJDIR/include -o c-family/c-gimplify.o -MT c-family/c-gimplify.o -MMD -MP -MF c-family/.deps/c-gimplify.TPo /gcc-5.20/gcc/c-family/c-gimplify.c
>> In file included from /gcc-5.20/gcc/flags.h:24:0,
>> from /gcc-5.20/gcc/c-family/c-common.h:36,
>> from /gcc-5.20/gcc/c-family/c-gimplify.c:41:
>> ./options.h:10:0: error: unterminated #if
>> #if !defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) && !defined(IN_RTS)
>> ^
>> ./options.h:3:0: error: unterminated #ifndef
>> #ifndef OPTIONS_H
>> ^
>> Makefile:1066: recipe for target 'c-family/c-gimplify.o' failed
>> make.exe[3]: *** [c-family/c-gimplify.o] Error 1
>> make.exe[3]: Leaving directory 'c:/build.gcc/gcc'
>> Makefile:4376: recipe for target 'all-stage1-gcc' failed
>> make.exe[2]: *** [all-stage1-gcc] Error 2
>> make.exe[2]: Leaving directory 'c:/build.gcc'
>> Makefile:17534: recipe for target 'stage1-bubble' failed
>> make.exe[1]: *** [stage1-bubble] Error 2
>> make.exe[1]: Leaving directory 'c:/build.gcc'
>> Makefile:17838: recipe for target 'bootstrap' failed
>> make.exe: *** [bootstrap] Error 2
>>
>> Same error do not repeat when I try to run 'sh ./djmake.sh bootstrap' again.
>>
>> Most likely explanation is that reading file (opened in binary mode) is unreliable
>> and one randomly gets corrupted data. Total data size is correct as libcpp compares
>> data size with one from response of stat() and reports an error in case of size discrepancy
>> (we needed to handle DOS end of file mark ^Z specially for that reason)
>>
>> It could be a bug in NTVDM. It could also be some problem on our side.
>> More testing is needed. Such test could repeatedly read some set of files into memory
>> and calculate MD5 sum or something similar to detect random corruptions. It would
>> be possible to investigate further and see what is getting corrupted
>>
>>
>> How to get DJGPP programs running on Windows 10 32 bit (please comment
>> if one has possibility to check on different edition)
>
> On of suspect is change to nmalloc. I have used it for a long time for GCC and there has been
> some instability related to it on Windows (different versions).
>
> My ancient test program written to test perfomance of memory allocation/freeing
>
> http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2007/12/05/17:54:46
>
> also randomly crashed on Windows when linked with nmalloc. I did not found them why it happens.
> Also WIndows 10 is not an exception as I have found in my test VM (Windows 10 Enterprise trial)
>
> Changed only one thing (added int _crt0_startup_flags = _CRT0_DISABLE_SBRK_ADDRESS_WRAP;
>
> And it seems to help in case of Windows 10 as the test program has run for several hours more
> than 2000 times without any crash (command line parameter value 20000000). Rebuild of
> gcc-5.2.0 with this flag set is ongoing on another system, so I'll be able to see whether it fixes the problem.
>
> Also: trying to set _CRT0_FLAG_UNIX_SBRK caused test program to crash immediately on Windows 10.
> I have not tried to investigate it further yet.
>
> Andris
>


That is a very serious show-stopper for 2.05 IMHO.  If we cannot trust our
memory system we cannot release.  IIRC Charles Sandman told in some mail
some weeks or months ago that the same fast allocation/deallocation speed
can be achieved with the old code by deactivating some DOS specific feature
that is of limited usefullness nowadays.  May be it is worth to think
about some switch to change between boths?  But I have no preferences.

I have observed a lot of times that bash crashes when running very large
configure scripts.  The only way to get the package configured is to run
the script again and again until the configuration process succeeds.  I do
not know if this has any relation to what you have described.

Have you already tested on Windows 10 home 32-bit?  Makes it sense that I try it?

Another question is should all the information required to install DJGPP on Windows 7
and Windows 10 be added in a detailed maner to the FAQ?


Regards,
Juan M. Guerrero
0
Juan
10/12/2015 1:01:01 AM
Am 04.10.2015 18:40, schrieb Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com]:
> I have earlier noticed random stray compile errors when building
> DJGPP port of gcc under Windows Vista Business. Running make again
> compiled some file without problems. Such errors where
> extremely rare for DJGPP CVS from CVS (also 2.04 before bumping version
> to 2.05). I usually did not get them at all for 2.04 or 2.05. The situation
> was noticeably worse for 2.03p2. Building GCC was still possible but I had to
> restart build often enough.
>
> I have 64-bit Windows 10 (earlier Windows 7) on desktop computer and dual boot
> with Linux (currently Fedora 22 x86_64). So there no DJGPP testing possible in this
> Windows installation for understandable reasons.
>
> Today downloaded 32 bit Windows 10 Enterprise 90 days trial from Microsoft and
> installed it in VirtualBox VM under Linux. I needed slightly more steps to get DJGPP
> working rather than on Windows Vista (for VIsta only registry hack was needed to
> workaround 32MB DMPI memory limit)
>
> Trying to build gcc-5.2.0 on this Windows 10 installation (DJGPP v2.05 only) showed
> that I'm getting stray compiler errors much more often (once per several minutes)
>
> These errors look like:
> gpp -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I/gcc-5.20/gcc -I/gcc-5.20/gcc/c-family -I/gcc-5.20/gcc/../include -I/gcc-5.20/gcc/../libcpp/include -I/gcc-5.20/gcc/../libdecnumber -I/gcc-5.20/gcc/../libdecnumber/dpd -I../libdecnumber -I/gcc-5.20/gcc/../libbacktrace -I/dev/env/DJDIR/include -o c-family/c-gimplify.o -MT c-family/c-gimplify.o -MMD -MP -MF c-family/.deps/c-gimplify.TPo /gcc-5.20/gcc/c-family/c-gimplify.c
> In file included from /gcc-5.20/gcc/flags.h:24:0,
> from /gcc-5.20/gcc/c-family/c-common.h:36,
> from /gcc-5.20/gcc/c-family/c-gimplify.c:41:
> ./options.h:10:0: error: unterminated #if
> #if !defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) && !defined(IN_RTS)
> ^
> ./options.h:3:0: error: unterminated #ifndef
> #ifndef OPTIONS_H
> ^
> Makefile:1066: recipe for target 'c-family/c-gimplify.o' failed
> make.exe[3]: *** [c-family/c-gimplify.o] Error 1
> make.exe[3]: Leaving directory 'c:/build.gcc/gcc'
> Makefile:4376: recipe for target 'all-stage1-gcc' failed
> make.exe[2]: *** [all-stage1-gcc] Error 2
> make.exe[2]: Leaving directory 'c:/build.gcc'
> Makefile:17534: recipe for target 'stage1-bubble' failed
> make.exe[1]: *** [stage1-bubble] Error 2
> make.exe[1]: Leaving directory 'c:/build.gcc'
> Makefile:17838: recipe for target 'bootstrap' failed
> make.exe: *** [bootstrap] Error 2
>
> Same error do not repeat when I try to run 'sh ./djmake.sh bootstrap' again.
>
> Most likely explanation is that reading file (opened in binary mode) is unreliable
> and one randomly gets corrupted data. Total data size is correct as libcpp compares
> data size with one from response of stat() and reports an error in case of size discrepancy
> (we needed to handle DOS end of file mark ^Z specially for that reason)
>
> It could be a bug in NTVDM. It could also be some problem on our side.
> More testing is needed. Such test could repeatedly read some set of files into memory
> and calculate MD5 sum or something similar to detect random corruptions. It would
> be possible to investigate further and see what is getting corrupted
>
>
> How to get DJGPP programs running on Windows 10 32 bit (please comment
> if one has possibility to check on different edition)
>
> Steps needed to get DJGPP apps running on 32 bit WIndows 10 enterprise trial version.
> It may be different in Win 10 Home or WIn 10 Pro. I just do not know.
>
> 1) Dialog asking confirmation for installing NTVDM appears when trying
> to run DJGPP program first time: You need to allow it to be run any DJGPP
> executable (it was when I tried to run unzip32.exe)
>
> 2) 32 MB DPMI memory limit is still present. Use old hack from Windows Vista
> epoch to got around it: Add registry entry DpmiLimit with large enough
> value to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW.
> No need to restart Windows. It's active immediately.
> I used value 0x7FFFFFFF and it is accepted and works
>
> 3) Command prompt configuration: mark check box "Use legacy console" active.
> Otherwise ls.exe, bash.exe, less.exe and other similar programs will not work and Windows
> will report NTVDM error
>
> Andris
>


Only for the record, I have compiled gcc520s.zip out-of-the-box a multpile of
times during the last week using a clean DJGPP 2.05 installation as described in:
   <http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/09/27/10:30:09>
on Win2K SP5 and WinXP SP3 without any difficulties.  Every build took around 12h
on a virtual machine, so acouple of days have been invested in this test.

On Win98SE (GUI) the build failed with the following output:

c:/djgpp-2.05/bin/sh.exe ./libtool  --tag=CC   --mode=compile /dev/d/gnu/build.gcc/./gcc/xgcc -B/dev/d/gnu/build.gcc/./gcc/ -B/dev/env/DJDIR/djgpp/bin/ -B/dev/env/DJDIR/djgpp/lib/ -isystem /dev/env/DJDIR/djgpp/include -isystem /dev/env/DJDIR/djgpp/sys-include    -DHAVE_CONFIG_H -I. -I/gnu/gcc-5.20/libgfortran  -iquote/gnu/gcc-5.20/libgfortran/io -I/gnu/gcc-5.20/libgfortran/../gcc -I/gnu/gcc-5.20/libgfortran/../gcc/config -I/gnu/gcc-5.20/libgfortran/../libquadmath -I../.././gcc -I/gnu/gcc-5.20/libgfortran/../libgcc -I../libgcc  -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections   -g -O2 -MT size_from_kind.lo -MD -MP -MF .deps/size_from_kind.Tpo -c -o size_from_kind.lo `test -f 'io/size_from_kind.c' || echo '/gnu/gcc-5.20/libgfortran/'`io/size_from_kind.c
libtool: compile:  /dev/d/gnu/build.gcc/./gcc/xgcc -B/dev/d/gnu/build.gcc/./gcc/ -B/dev/env/DJDIR/djgpp/bin/ -B/dev/env/DJDIR/djgpp/lib/ -isystem /dev/env/DJDIR/djgpp/include -isystem /dev/env/DJDIR/djgpp/sys-include -DHAVE_CONFIG_H -I. -I/gnu/gcc-5.20/libgfortran -iquote/gnu/gcc-5.20/libgfortran/io -I/gnu/gcc-5.20/libgfortran/../gcc -I/gnu/gcc-5.20/libgfortran/../gcc/config -I/gnu/gcc-5.20/libgfortran/../libquadmath -I../.././gcc -I/gnu/gcc-5.20/libgfortran/../libgcc -I../libgcc -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT size_from_kind.lo -MD -MP -MF .deps/size_from_kind.Tpo -c /gnu/gcc-5.20/libgfortran/io/size_from_kind.c -o size_from_kind.o
mv -f .deps/size_from_kind.Tpo .deps/size_from_kind.Plo
c:/djgpp-2.05/bin/sh.exe ./libtool  --tag=CC   --mode=compile /dev/d/gnu/build.gcc/./gcc/xgcc -B/dev/d/gnu/build.gcc/./gcc/ -B/dev/env/DJDIR/djgpp/bin/ -B/dev/env/DJDIR/djgpp/lib/ -isystem /dev/env/DJDIR/djgpp/include -isystem /dev/env/DJDIR/djgpp/sys-include    -DHAVE_CONFIG_H -I. -I/gnu/gcc-5.20/libgfortran  -iquote/gnu/gcc-5.20/libgfortran/io -I/gnu/gcc-5.20/libgfortran/../gcc -I/gnu/gcc-5.20/libgfortran/../gcc/config -I/gnu/gcc-5.20/libgfortran/../libquadmath -I../.././gcc -I/gnu/gcc-5.20/libgfortran/../libgcc -I../libgcc  -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections   -g -O2 -MT close.lo -MD -MP -MF .deps/close.Tpo -c -o close.lo `test -f 'io/close.c' || echo '/gnu/gcc-5.20/libgfortran/'`io/close.c
libtool: compile:  /dev/d/gnu/build.gcc/./gcc/xgcc -B/dev/d/gnu/build.gcc/./gcc/ -B/dev/env/DJDIR/djgpp/bin/ -B/dev/env/DJDIR/djgpp/lib/ -isystem /dev/env/DJDIR/djgpp/include -isystem /dev/env/DJDIR/djgpp/sys-include -DHAVE_CONFIG_H -I. -I/gnu/gcc-5.20/libgfortran -iquote/gnu/gcc-5.20/libgfortran/io -I/gnu/gcc-5.20/libgfortran/../gcc -I/gnu/gcc-5.20/libgfortran/../gcc/config -I/gnu/gcc-5.20/libgfortran/../libquadmath -I../.././gcc -I/gnu/gcc-5.20/libgfortran/../libgcc -I../libgcc -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT close.lo -MD -MP -MF .deps/close.Tpo -c /gnu/gcc-5.20/libgfortran/io/close.c -o close.o
/gnu/gcc-5.20/libgfortran/io/close.c: In Funktion »st_close«:
/gnu/gcc-5.20/libgfortran/io/close.c:75:11: Fehler: Implizite Deklaration der Funktion »strdup« [-Werror=implicit-function-declaration]
     path = strdup (u->filename);
            ^
/gnu/gcc-5.20/libgfortran/io/close.c:75:11: Warnung: UnvertrÀgliche implizite Deklaration der eingebauten Funktion »strdup«
/gnu/gcc-5.20/libgfortran/io/close.c:85:15: Warnung: UnvertrÀgliche implizite Deklaration der eingebauten Funktion »strdup«
         path = strdup (u->filename);
                ^
/gnu/gcc-5.20/libgfortran/io/close.c:95:4: Fehler: Implizite Deklaration der Funktion »unlink« [-Werror=implicit-function-declaration]
     unlink (path);
     ^
cc1.exe: Einige Warnungen werden als Fehler behandelt
Makefile:5137: recipe for target 'close.lo' failed
make.exe[3]: *** [close.lo] Error 1
make.exe[3]: Leaving directory 'd:/gnu/build.gcc/djgpp/libgfortran'
Makefile:1297: recipe for target 'all' failed
make.exe[2]: *** [all] Error 2
make.exe[2]: Leaving directory 'd:/gnu/build.gcc/djgpp/libgfortran'
Makefile:15584: recipe for target 'all-target-libgfortran' failed
make.exe[1]: *** [all-target-libgfortran] Error 2
make.exe[1]: Leaving directory 'd:/gnu/build.gcc'
Makefile:17838: recipe for target 'bootstrap' failed
make.exe: *** [bootstrap] Error 2

I have not investigated this further.  The generation of numeric tails for file
names must be enabled to get the zip file extracted in a working fashion.
I do not know if this is worth to be fixed.
Specially I have not tried to build it on DOS 7.0 with a LFN driver.  This would
even more slower than using Win98SE (GUI).


Regards,
Juan M. Guerrero
0
Juan
10/12/2015 5:26:37 PM
On 10/12/2015 09:04 PM, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] wrote:
> Am 11.10.2015 13:45, schrieb Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com]:
>> On 10/04/2015 07:40 PM, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
>>> I have earlier noticed random stray compile errors when building
>>> DJGPP port of gcc under Windows Vista Business. Running make again
>>> compiled some file without problems. Such errors where
>>> extremely rare for DJGPP CVS from CVS (also 2.04 before bumping version
>>> to 2.05). I usually did not get them at all for 2.04 or 2.05. The situation
>>> was noticeably worse for 2.03p2. Building GCC was still possible but I had to
>>> restart build often enough.
>>>
>>> I have 64-bit Windows 10 (earlier Windows 7) on desktop computer and dual boot
>>> with Linux (currently Fedora 22 x86_64). So there no DJGPP testing possible in this
>>> Windows installation for understandable reasons.
>>>
>>> Today downloaded 32 bit Windows 10 Enterprise 90 days trial from Microsoft and
>>> installed it in VirtualBox VM under Linux. I needed slightly more steps to get DJGPP
>>> working rather than on Windows Vista (for VIsta only registry hack was needed to
>>> workaround 32MB DMPI memory limit)
>>>
>>> Trying to build gcc-5.2.0 on this Windows 10 installation (DJGPP v2.05 only) showed
>>> that I'm getting stray compiler errors much more often (once per several minutes)
>>>
>>> These errors look like:
>>> gpp -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti 
>>> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
>>> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
>>> -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I/gcc-5.20/gcc 
>>> -I/gcc-5.20/gcc/c-family -I/gcc-5.20/gcc/../include -I/gcc-5.20/gcc/../libcpp/include 
>>> -I/gcc-5.20/gcc/../libdecnumber -I/gcc-5.20/gcc/../libdecnumber/dpd -I../libdecnumber 
>>> -I/gcc-5.20/gcc/../libbacktrace -I/dev/env/DJDIR/include -o c-family/c-gimplify.o -MT 
>>> c-family/c-gimplify.o -MMD -MP -MF c-family/.deps/c-gimplify.TPo 
>>> /gcc-5.20/gcc/c-family/c-gimplify.c
>>> In file included from /gcc-5.20/gcc/flags.h:24:0,
>>> from /gcc-5.20/gcc/c-family/c-common.h:36,
>>> from /gcc-5.20/gcc/c-family/c-gimplify.c:41:
>>> ./options.h:10:0: error: unterminated #if
>>> #if !defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) && !defined(IN_RTS)
>>> ^
>>> ./options.h:3:0: error: unterminated #ifndef
>>> #ifndef OPTIONS_H
>>> ^
>>> Makefile:1066: recipe for target 'c-family/c-gimplify.o' failed
>>> make.exe[3]: *** [c-family/c-gimplify.o] Error 1
>>> make.exe[3]: Leaving directory 'c:/build.gcc/gcc'
>>> Makefile:4376: recipe for target 'all-stage1-gcc' failed
>>> make.exe[2]: *** [all-stage1-gcc] Error 2
>>> make.exe[2]: Leaving directory 'c:/build.gcc'
>>> Makefile:17534: recipe for target 'stage1-bubble' failed
>>> make.exe[1]: *** [stage1-bubble] Error 2
>>> make.exe[1]: Leaving directory 'c:/build.gcc'
>>> Makefile:17838: recipe for target 'bootstrap' failed
>>> make.exe: *** [bootstrap] Error 2
>>>
>>> Same error do not repeat when I try to run 'sh ./djmake.sh bootstrap' again.
>>>
>>> Most likely explanation is that reading file (opened in binary mode) is unreliable
>>> and one randomly gets corrupted data. Total data size is correct as libcpp compares
>>> data size with one from response of stat() and reports an error in case of size discrepancy
>>> (we needed to handle DOS end of file mark ^Z specially for that reason)
>>>
>>> It could be a bug in NTVDM. It could also be some problem on our side.
>>> More testing is needed. Such test could repeatedly read some set of files into memory
>>> and calculate MD5 sum or something similar to detect random corruptions. It would
>>> be possible to investigate further and see what is getting corrupted
>>>
>>>
>>> How to get DJGPP programs running on Windows 10 32 bit (please comment
>>> if one has possibility to check on different edition)
>>
>> On of suspect is change to nmalloc. I have used it for a long time for GCC and there has been
>> some instability related to it on Windows (different versions).
>>
>> My ancient test program written to test perfomance of memory allocation/freeing
>>
>> http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2007/12/05/17:54:46
>>
>> also randomly crashed on Windows when linked with nmalloc. I did not found them why it happens.
>> Also WIndows 10 is not an exception as I have found in my test VM (Windows 10 Enterprise trial)
>>
>> Changed only one thing (added int _crt0_startup_flags = _CRT0_DISABLE_SBRK_ADDRESS_WRAP;
>>
>> And it seems to help in case of Windows 10 as the test program has run for several hours more
>> than 2000 times without any crash (command line parameter value 20000000). Rebuild of
>> gcc-5.2.0 with this flag set is ongoing on another system, so I'll be able to see whether it 
>> fixes the problem.
>>
>> Also: trying to set _CRT0_FLAG_UNIX_SBRK caused test program to crash immediately on Windows 10.
>> I have not tried to investigate it further yet.
>>
>> Andris
>>
>
>
> That is a very serious show-stopper for 2.05 IMHO.  If we cannot trust our
> memory system we cannot release.  IIRC Charles Sandman told in some mail
> some weeks or months ago that the same fast allocation/deallocation speed
> can be achieved with the old code by deactivating some DOS specific feature
> that is of limited usefullness nowadays.  May be it is worth to think
> about some switch to change between boths?  But I have no preferences.
>
> I have observed a lot of times that bash crashes when running very large
> configure scripts.  The only way to get the package configured is to run
> the script again and again until the configuration process succeeds.  I do
> not know if this has any relation to what you have described.
>
> Have you already tested on Windows 10 home 32-bit?  Makes it sense that I try it?
>
> Another question is should all the information required to install DJGPP on Windows 7
> and Windows 10 be added in a detailed maner to the FAQ?
>
Rebulding gcc-5.2.0 with _CRT0_DISABLE_SBRK_ADDRESS_WRAP did not help.

I wrote simple script that only preprocessed same source file from GCC sources
many time and compared output of preprocessor and got random differences in
preprocessor output (after several hunderds iof thousends of retries)

Also there were similar problem on Windows Vista Business where I'm normally built
DJGPP packages but for DJGPP v2.03p2 only. DJGPP v2.05 seems to be much more stable
there.

Andris

0
Andris
10/12/2015 6:19:27 PM
Am 16.10.2015 20:20, schrieb Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com]:
> On 10/11/2015 02:45 PM, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
>> On 10/04/2015 07:40 PM, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
>>> I have earlier noticed random stray compile errors when building
>>> DJGPP port of gcc under Windows Vista Business. Running make again
>>> compiled some file without problems. Such errors where
>>> extremely rare for DJGPP CVS from CVS (also 2.04 before bumping version
>>> to 2.05). I usually did not get them at all for 2.04 or 2.05. The situation
>>> was noticeably worse for 2.03p2. Building GCC was still possible but I had to
>>> restart build often enough.
>>>
>>> I have 64-bit Windows 10 (earlier Windows 7) on desktop computer and dual boot
>>> with Linux (currently Fedora 22 x86_64). So there no DJGPP testing possible in this
>>> Windows installation for understandable reasons.
>>>
>>> Today downloaded 32 bit Windows 10 Enterprise 90 days trial from Microsoft and
>>> installed it in VirtualBox VM under Linux. I needed slightly more steps to get DJGPP
>>> working rather than on Windows Vista (for VIsta only registry hack was needed to
>>> workaround 32MB DMPI memory limit)
>>>
>>> Trying to build gcc-5.2.0 on this Windows 10 installation (DJGPP v2.05 only) showed
>>> that I'm getting stray compiler errors much more often (once per several minutes)
>>>
>>> These errors look like:
>>> gpp -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I/gcc-5.20/gcc -I/gcc-5.20/gcc/c-family -I/gcc-5.20/gcc/../include -I/gcc-5.20/gcc/../libcpp/include -I/gcc-5.20/gcc/../libdecnumber -I/gcc-5.20/gcc/../libdecnumber/dpd -I../libdecnumber -I/gcc-5.20/gcc/../libbacktrace -I/dev/env/DJDIR/include -o c-family/c-gimplify.o -MT c-family/c-gimplify.o -MMD -MP -MF c-family/.deps/c-gimplify.TPo /gcc-5.20/gcc/c-family/c-gimplify.c
>>> In file included from /gcc-5.20/gcc/flags.h:24:0,
>>> from /gcc-5.20/gcc/c-family/c-common.h:36,
>>> from /gcc-5.20/gcc/c-family/c-gimplify.c:41:
>>> ./options.h:10:0: error: unterminated #if
>>> #if !defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) && !defined(IN_RTS)
>>> ^
>>> ./options.h:3:0: error: unterminated #ifndef
>>> #ifndef OPTIONS_H
>>> ^
>>> Makefile:1066: recipe for target 'c-family/c-gimplify.o' failed
>>> make.exe[3]: *** [c-family/c-gimplify.o] Error 1
>>> make.exe[3]: Leaving directory 'c:/build.gcc/gcc'
>>> Makefile:4376: recipe for target 'all-stage1-gcc' failed
>>> make.exe[2]: *** [all-stage1-gcc] Error 2
>>> make.exe[2]: Leaving directory 'c:/build.gcc'
>>> Makefile:17534: recipe for target 'stage1-bubble' failed
>>> make.exe[1]: *** [stage1-bubble] Error 2
>>> make.exe[1]: Leaving directory 'c:/build.gcc'
>>> Makefile:17838: recipe for target 'bootstrap' failed
>>> make.exe: *** [bootstrap] Error 2
>>>
>>> Same error do not repeat when I try to run 'sh ./djmake.sh bootstrap' again.
>>>
>>> Most likely explanation is that reading file (opened in binary mode) is unreliable
>>> and one randomly gets corrupted data. Total data size is correct as libcpp compares
>>> data size with one from response of stat() and reports an error in case of size discrepancy
>>> (we needed to handle DOS end of file mark ^Z specially for that reason)
>>>
>>> It could be a bug in NTVDM. It could also be some problem on our side.
>>> More testing is needed. Such test could repeatedly read some set of files into memory
>>> and calculate MD5 sum or something similar to detect random corruptions. It would
>>> be possible to investigate further and see what is getting corrupted
>>>
>>>
>>> How to get DJGPP programs running on Windows 10 32 bit (please comment
>>> if one has possibility to check on different edition)
>>
> Tried to investigate on same Win 10 Enterprise trial VM but no success up to this time:
>
> modified gcc/libcpp/files.c to calculate and dump to stderr MD5 sums of just read files.
> Did not notice any problems reading files when repeated it may times (sort | uniq) even
> when I had stray preprocessor output differences and errors (like missing #endif). So
> reading files do not seem to be reason of problems
>
> Suspected use of -remap (DJGPP is perhaps only target for which it is used, had to fix a
> related error rather long time ago). No influence
>
> Some more thoughts:
>
> 1) random DPMI memory corruption (for example from interrupts) in Windows (especially WIndows 10).
> One would need a program that uses much memory and runs long enough and for which result can
> be easily verified. https://gmplib.org/pi-with-gmp.html could be good candidate
> 2) some problem on our side (for example use os uninitialized data)
>
> In case of (1) we may be out of luck.
>
> There was however similar problems with DJGPP v2.03p2 on Windows Vista, which I have not
> any more noticed with 2.05.
>
> Andris
>

Please do not get me wrong, I really appreciate your efforts but all of your
activity seems to imply that this will be again another week-end without the
release of DJGPP 2.05.
Are there any realistic chances that we will release DJGPP 2.05 before the end
of the year?  We are already working for at least 6 months on this.

I really fear that we are again on the road to nowhere like with DJGPP 2.04.
I gain the impression that we are confusing real impediments, that do not exist
at all,  with particular features that some developer would like to see implemented
before this release gets released.  No matter if we are talking about something like
DXE support or if we are talking about windows 10 support.

I would like to recall to all interested people that DJGPP is a 32-bit application
that has been devolped to run on MS-DOS 3.1 or compatible operating systems that do
either provide some kind of DPMI server or allow to install one.  Absolute no one
has ever promised that DJGPP would work on Vista, Windows 7, Windows 8, Windows 10
or what ever they may invent in the future.  AFAIK Microsoft has clearly state that
they are no longer interested in suporting MS-DOS applications on their OSs.
And all DJGPP programs are MS-DOS applications that require a full functional
DOS environment to work flawlessly, so IMO it becomes very unlikely that the
goal of getting DJGPP working on modern Windows operating systems can ever be
achived.  I am not opposing on trying to get DJGPP working on Windows 10 or
similar OS but in consideration of the fact of the small amount of DJGPP users
and the even smaller amount of skilled DJGPP developers really familiar with
DJGPP internals and Windows internals, this will take at least a couple of months
more, probably it will take years.  IMO, an attempt to get DJGPP working on
Windows 10 or similar operating systems shall be postponed until 205 has been
released.  The over the years vanishing group of DJGPP users do not deserve to
wait until the end of days for this release.  I really think that we shall take
seriously user questions like this one:
  http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/09/29/12:45:12
and give a honest answer about when we definitively plan to release this thing.

The last Microsoft operating system I have bought was Windows XP and I have no
intentions to buy any other any more.  This means that I do not really care if
DJGPP works on Windows Vista and similar OS.  If an user like me decides to try
and to use DJGPP at all, then he is absolutely _aware_ that DJGPP is a DOS
application and that it will certainly not run on any modern Microsoft operating
system.
Who says DJGPP is saying DOS and certainly not Windows specially not Windows 10.

I think that I have proved, by all my checks lately done on MSDOS-6.22, Win98SE,
Win2K and WinXP, that DJGPP as-it-is-now is absolute stable and is ready to be
released right now.  DJGPP does _NOT_ address any other operating system than
the ones stipulated in the previous sentence and probably will never do, so we
do not need to care about them.  At least we do not need to care right now.

We should concentrate the efforts on a quick release and not waist time defining
goals that cannot be achived and then become impediments for the release.  DJGPP
is a DOS application and never will become Windows application.  Basta.

Please do not get me wrong.  If the things I have expressed sounds rough it is
only due to my limited english skills.  There is no offending intention here.
But from the experience of the last months envolved in this issue, I have seen
confirmed again what I have learned in 25 years of working in the software industry:
every release of a software needs at least 2 things:
1) one and only one release manager that is responsible for the release and
    with the absolute power to make decisions
2) a deadline that is binding for all involved personnel
Without these 2 things we do not come to an end and we start to confuse issues
of the category "nice-to-have" with real requirements.
During the time being envolved in this issue sometimes I had the strong impression
that we all were sailing on the titanic and the captain is missing.

I really hope that we can quickly come to a release of DJGPP 2.05 or if not
then I expect a clear explanation from you about what is missing and in which
period of time you think that the missing and required feature can be provided
by you.  Without this information, we cannot decide if this feature is worth to
be waiting for.


Some weeks ago I send to DJ my latest version of the script together with a set
of 00_index.txt files for all new /current directories that will be created by
the release.  If nothing has changed in the actual /beta tree we can proceed
with the release of DJGPP in the near future.  I really do not see any impediments
at all.

Meanwhile I have also inspected the patch submitted by Ozkan:
   <http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/10/05/05:32:54>
to improve the DXE module support.  It looks OK to me and I think
it should go into the DJGPP 2.05 code.  IMO this should be the _absolute last_
change allowed to be commited into the v2_05_1 branch and then we should release.


 > There was however similar problems with DJGPP v2.03p2 on Windows Vista, which I have not
 > any more noticed with 2.05.

I have also not observed any nmalloc releated issues in the last months when
I used it.  I think that we can accept it as new memory system for DJGPP.


Regards,
Juan M. Guerrero
0
Juan
10/16/2015 1:01:01 AM
On 10/11/2015 02:45 PM, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
> On 10/04/2015 07:40 PM, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
>> I have earlier noticed random stray compile errors when building
>> DJGPP port of gcc under Windows Vista Business. Running make again
>> compiled some file without problems. Such errors where
>> extremely rare for DJGPP CVS from CVS (also 2.04 before bumping version
>> to 2.05). I usually did not get them at all for 2.04 or 2.05. The situation
>> was noticeably worse for 2.03p2. Building GCC was still possible but I had to
>> restart build often enough.
>>
>> I have 64-bit Windows 10 (earlier Windows 7) on desktop computer and dual boot
>> with Linux (currently Fedora 22 x86_64). So there no DJGPP testing possible in this
>> Windows installation for understandable reasons.
>>
>> Today downloaded 32 bit Windows 10 Enterprise 90 days trial from Microsoft and
>> installed it in VirtualBox VM under Linux. I needed slightly more steps to get DJGPP
>> working rather than on Windows Vista (for VIsta only registry hack was needed to
>> workaround 32MB DMPI memory limit)
>>
>> Trying to build gcc-5.2.0 on this Windows 10 installation (DJGPP v2.05 only) showed
>> that I'm getting stray compiler errors much more often (once per several minutes)
>>
>> These errors look like:
>> gpp -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti 
>> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
>> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
>> -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Ic-family -I/gcc-5.20/gcc 
>> -I/gcc-5.20/gcc/c-family -I/gcc-5.20/gcc/../include -I/gcc-5.20/gcc/../libcpp/include 
>> -I/gcc-5.20/gcc/../libdecnumber -I/gcc-5.20/gcc/../libdecnumber/dpd -I../libdecnumber 
>> -I/gcc-5.20/gcc/../libbacktrace  -I/dev/env/DJDIR/include -o c-family/c-gimplify.o -MT 
>> c-family/c-gimplify.o -MMD -MP -MF c-family/.deps/c-gimplify.TPo 
>> /gcc-5.20/gcc/c-family/c-gimplify.c
>> In file included from /gcc-5.20/gcc/flags.h:24:0,
>>                  from /gcc-5.20/gcc/c-family/c-common.h:36,
>>                  from /gcc-5.20/gcc/c-family/c-gimplify.c:41:
>> ./options.h:10:0: error: unterminated #if
>>  #if !defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) && !defined(IN_RTS)
>>  ^
>> ./options.h:3:0: error: unterminated #ifndef
>>  #ifndef OPTIONS_H
>>  ^
>> Makefile:1066: recipe for target 'c-family/c-gimplify.o' failed
>> make.exe[3]: *** [c-family/c-gimplify.o] Error 1
>> make.exe[3]: Leaving directory 'c:/build.gcc/gcc'
>> Makefile:4376: recipe for target 'all-stage1-gcc' failed
>> make.exe[2]: *** [all-stage1-gcc] Error 2
>> make.exe[2]: Leaving directory 'c:/build.gcc'
>> Makefile:17534: recipe for target 'stage1-bubble' failed
>> make.exe[1]: *** [stage1-bubble] Error 2
>> make.exe[1]: Leaving directory 'c:/build.gcc'
>> Makefile:17838: recipe for target 'bootstrap' failed
>> make.exe: *** [bootstrap] Error 2
>>
>> Same error do not repeat when I try to run 'sh ./djmake.sh bootstrap' again.
>>
>> Most likely explanation is that reading file (opened in binary mode) is unreliable
>> and one randomly gets corrupted data. Total data size is correct as libcpp compares
>> data size with one from response of stat() and reports an error in case of size discrepancy
>> (we needed to handle DOS end of file mark ^Z specially for that reason)
>>
>> It could be a bug in NTVDM. It could also be some problem on our side.
>> More testing is needed. Such test could repeatedly read some set of files into memory
>> and calculate MD5 sum or something similar to detect random corruptions. It would
>> be possible to investigate further and see what is getting corrupted
>>
>>
>> How to get DJGPP programs running on Windows 10 32 bit (please comment
>> if one has possibility to check on different edition)
>
Tried to investigate on same Win 10 Enterprise trial VM but no success up to this time:

modified gcc/libcpp/files.c to calculate and dump to stderr MD5 sums of just read files.
Did not notice any problems reading files when repeated it may times (sort | uniq) even
when I had stray preprocessor output differences and errors (like missing #endif). So
reading files do not seem to be reason of problems

Suspected use of -remap (DJGPP is perhaps only target for which it is used, had to fix a
related error rather long time ago). No influence

Some more thoughts:

1) random DPMI memory corruption (for example from interrupts) in Windows (especially WIndows 10).
One would need a program that uses much memory and runs long enough and for which result can
  be easily verified. https://gmplib.org/pi-with-gmp.html could be good candidate
2) some problem on our side (for example use os uninitialized data)

In case of (1) we may be out of luck.

There was however similar problems with DJGPP v2.03p2 on Windows Vista, which I have not
any more noticed with 2.05.

Andris

0
Andris
10/16/2015 6:20:18 PM
Sorry that I cannot help you with it. I can only say that my largest projec=
t, that I compiled with DJGPP is my FFMPEG DOS port consist of tens MB of s=
ource file and I never experienced any random errors described here. I use =
WXP SP3 for this task. I have newer Windows installed but only in VMs, just=
 for testing. I can see that NTVDM is more and more crippled with every new=
er Windows version - simple because MSDOS is out of MS scope now and if som=
ething breaks then nobody will fix it because MS allocated developers for i=
mproving people spying and enforcing W10 upgrade to everybody so no resourc=
es left for fixing NTVDM :P
I guess they will completly drop it soon. Esp. in Win10 I found some NTVDM =
bugs that didn't present in Win 7/8.x. I really wouldn't wonder if there ha=
ppens some random DPMI corruption that was mentioned above... But I don't k=
noh how it's linked with change to nmalloc, if such errors happen without i=
t too.
I wish you enough power to release 2.05 :)
0
RayeR
10/16/2015 11:16:37 PM
On 10/17/2015 12:14 AM, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] wrote:
> Please do not get me wrong, I really appreciate your efforts but all of your
> activity seems to imply that this will be again another week-end without the
> release of DJGPP 2.05.
> Are there any realistic chances that we will release DJGPP 2.05 before the end
> of the year?  We are already working for at least 6 months on this.
>
> I really fear that we are again on the road to nowhere like with DJGPP 2.04.
> I gain the impression that we are confusing real impediments, that do not exist
> at all,  with particular features that some developer would like to see implemented
> before this release gets released.  No matter if we are talking about something like
> DXE support or if we are talking about windows 10 support.
>
It is up to us to decide which problems to consider show-stoppers. If gcc developers would try to
completely clean up all known bugs they would never release a single version.

I do not think that instability of GCC preprocessor under WIndows 10 should delay release unless
there are other significant problems. It should however be OK to discuss DJGPP problems when
used under WIndows 10.

We could release DJGPP v2.06 soon enough if really critical problems wuold be found and fixed
soon. That would not require so much efforts as current release due to smaller amount of
changes

About current instability:

- nmalloc problems mentioned earlier are not source. They were present also for Windows Vista
which I used to build GCC packages available on ftp.delorie.com and they did not prevent
me from building GCC. These problems do not appear to be source of difficulties also
under Windows 10

- there seems to be no instability in running some other DJGPP programs. I tried program
for calculating arbitrary number of decimal signs of number pi I mentioned in earlier message.
No problems detected trying to calculate 100000000 decimal signs of pi under Windows 10.
That required near 1GB of DPMI memory and took more than 5 minutes per run.

- random DPMI corruption would much more likely bite actual compiler not preprocessor due to larger
amount of required resources

After all that I'm more inclined to think that the problem lies on our side. There could be slight
differences between different DPMI providers that could trigger problems. I have some more
ideas to try but I would not like to discuss them before trying.

It may also take time to fix the problem if really found.

So guess we should actually release 2.05 now.

Andris




0
Andris
10/17/2015 4:53:07 AM
> So guess we should actually release 2.05 now.

While it's ultimately up to you and Juan, I agree :-)
0
DJ
10/17/2015 4:55:26 AM
On 10/17/2015 12:53 AM, Andris Pavenis (andris.pavenis@iki.fi) [via 
djgpp@delorie.com] wrote:
>
> After all that I'm more inclined to think that the problem lies on our
> side. There could be slight
> differences between different DPMI providers that could trigger
> problems. I have some more
> ideas to try but I would not like to discuss them before trying.

There was something sezero and I noticed that may possibly be related to 
alignment issues with SSE and DXEs.  But, we have not yet 100% confirmed.

Very briefly, we got the source code to Sage, a minigl like driver that 
also had a DJGPP codepath (written by Daniel Borca who was a DJGPP 
contributor in the past).  I noticed that static linked builds to Q2DOS 
worked fine with Pentium 3 processors, but builds that used Sage as a 
DXE would usually start with a black screen (but actually dropped back 
to DOS so it could be blindly attempted to try and restart).

I somehow found out by mistake adding some extra parameters at startup 
would allow it to start every time, but the string length was dependent 
within a certain window and differed from machine.

Talking to the author of the code he suggested changing movaps to movups 
and see if that resolved the issue and it did.

He suggested that DXE may be affecting alignment, but we haven't done 
much more testing yet.

Not a complete show stopper since we were able to work around it with no 
performance degradation, but thought it may be worth mentioning for 2.06 
and before I forget about it.

Frank

0
Frank
10/17/2015 5:39:31 AM
On 10/17/2015 07:55 AM, DJ Delorie wrote:
>> So guess we should actually release 2.05 now.
> While it's ultimately up to you and Juan, I agree :-)
>
Especially when nmalloc is out of my list of suspects now as linking with old DJGPP v2.03
malloc and calloc do not fix the problem.

Andris

0
Andris
10/17/2015 7:15:28 AM
This is a multi-part message in MIME format.
--------------060800070802080106030001
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Am 17.10.2015 06:55, schrieb DJ Delorie:
>> So guess we should actually release 2.05 now.
>
> While it's ultimately up to you and Juan, I agree :-)

Unfortunately my mail has gone to DJ instead to djgpp@delorie.com as it was intended
so I send it a second time.
I only respond to this mail but I have read them all.

1) I have checked nmalloc by running the test code suggested by Andris in:
   <http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2007/12/05/17:54:46>
    I have test it on WinXP SP3, Win2K SP5 Win98SE and MSDOS-6.22.  All operating
    systems were installed on different virtual machines on a linux host.  Every
    virtual machine run alone and during the test no other programs were started
    by me.  Because they run very fast I have used the following script to run
    the test:

touch _start.txt
for i in 0 1 2 3 4 5 6 7 8 9; do
   for j in 0 1 2 3 4 5 6 7 8 9; do
     echo $i$j;
     for s in 500000 1000000 1500000 2000000 2500000; do
       ./memalloctest.exe $s;
     done
   done
done > 1.txt
touch _stop.txt


    Please note that I have increased the values of s by a power of ten compared
    with original script of Andris.  I have never experienced any issue on any OS.
    Unfortunately on MSDOS it took hours so I decided to reduce the value of s
    again to its original value.  For all test I have appended the redirected
    outout to this mail.  I have not changed the code of memalloctest.
    My conclusion is that nmalloc seems to run stable on the tested series of OS.
    If in the future we descover some issue we can always return to the old one
    and modify the code as proposed by Charles Sandmann in:
   <http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/03/31/21:15:14>

2) I plan to proceed as follow if no one (Andris, DJ) has serious objections:
    a) now it is 15:45 here in germany.  I will wait until 21:00 (local time) to
       see if Ozkan has committed his DXE module patch as presented in:
       <http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/10/04/13:58:46>
       I do not want to apply it because I do not know if that is really the
       final version.  If I see that he has not committed the patch, then this
       feature will definitively __NOT__ be part of the 205 release.
    b) After having verified the committe or not committe of the patch I will
       ask you, Andris, to compile and build one last time the dj***205.zip files
       und upload them until tomorrow to the ftp server.  If for some reason
       you cannot build them please let me know and I will do it using
       gcc520 and bnu2251br2 and WinXP.
    c) Tomorrow around 13:00 or 14:00 (local time) I will update my
       ftp.delori.com mirror and check/update my script and 00_index.txt files
       one last time.  When every thing has been verified to work, I will send
       the 00_index.txt files and the script to DJ so he can run it and produce
       the 205 release.  After he has notified me, I will update the weekly
       Mini-FAQ to reflect the new files.
    d) On monday you, Andris, or DJ can announce DJGPP 2.05.  I will certainly not
       do it.

3) As with every release it will be very likely that after a couple of days some
    user will report some isuue.  This should not bother at all.  After the release
    we will have a plenty of time to collect all this bug reports and to fix them.
    If there is real progress in any of the reported or pending issue we can always
    make a new release around 2016-12-31 or later.  There is no hurry in specifying
    a deadline for this now.

Now I will be out of home so do not expect any response.


Regards,
Juan M. Guerrero

--------------060800070802080106030001
Content-Type: application/x-bzip;
 name="nmalloc.tar.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="nmalloc.tar.bz2"

QlpoOTFBWSZTWRO4UK8Ao5D9hPASiChAA3/wAEJsn97AAACACGAa/lqC8AAAPAfZ4jY02AAA
PoAKAAQwAD6N0Im9dw5sZs9h977j5u2Rwjd9zO3d3O3n33u9PgGSYNJFIMmNCADI0BqegYqq
MlABggAAIe1SqkxNMEyNDIDQxGBJ6pKSR6pPaoAA0AAAKUhSaZMSKBoZGgGaj1BElDYqp5TU
I9TAjTIaGg3f0Pv+p8mGq50A4VTyMCwwD65/DNyQqcGGFoiS0fCEEggT3dw7ZrpUV06LpN00
U9wG1DxzdTrAhAtzBtOut5uVo5lxQ4rOJbvbGxSxy+7bWnuM0Jlkq2AAQCoG9bYWn3lXvTpo
m9TEq124R9BFo6btyskUilrOLw3taLp3NwqrPREV05m7w3W7QXKPrVXKndHBaXcWor2FXKST
lOccOypzu0re5K6rvOrDFVZdbuQvLdOPSgq7HtN5A7e4RbaMkay8R6gzrY7JetqQ6h16O19i
kGN5ucogayLx2zLQeVmhOwACQQN9V1BBIALsPzV+lfKva21W2u+r7wxCRCaCTRYAxCKYlBSQ
INtBaxQWDMyGymhjSWUjY1RUZljRio2SkYTSKCIGSkxCBkDEMLNJo1JEQmJKQ2iKSoZjFTTE
hFkqCDGjBFSRIbFFNrFUhRYMlUljaNPvulICVuU7ld3NGiK5sFjruxI6tyo2YRElBBoqRCUV
Jo1SVjSRAaxbGpNFXV6GiCMzMkpTJAzCYEykkkIiCTQFJNjaKSpLMkKNhgs0I0mxJiQSLMmV
V99dZRGsloRkaMZMzE2ZlmQxioMMmgbGxiiAaCRIA2M1jGiJIiZBilKhhVHnRtJbW1tM8BdY
GCTOmc2Jb110lvWrpbNrC2l1tLpJhtbMGOY4zmOtmBiZ0usDOM62JbMJgwxzZhYMcYmJJCSG
cRvWuYb3b3MMdM6SZxCNi5jmFtbSSTDZvds3uSx1jpGFvcqoqoVVFde64iICp/oIioCpw8jI
w0USEGG/H117r9fnfpfnJ8T8l9fj93134/Xp9eXfruygvr4cuiKJgkgo7uhWgfHPZ4aifH5h
FEQXU9ZJdujO9uHeoX5mFeYsTZGRJJOB7TQuBTpz2VwQboTNpU/TeHc/E+HgCfAeJAK0WNWL
RjUlTKgCRK32vfde90V3dq75rxZBjLztrY2UmJmBtChRoiEkYSMhIgVRA3WZIZmZchfRVWWe
QJUElNyG6ljDmVmrF2LbUPsIXmXoKL4TIZY4YOWOr4bLinMJOiMF0QxbvgtpHRrejXcEq6k4
y7CQ2C5tCrhr8fj31fZZMJK2aKQzFFXqlU8XXOy6UiEZGVNlY9LqqpGk2beJs2pI+eLcHV1s
ACgCQA8Rzhj2906It7OszvnO4ssoSoyCyMkCEAJEkVrlItIbQlisadvvrygiozTWMaai0hNe
15sgmDEzSosXGuXe6i0oO97aNl7t0kTRcqQKZM5L0OletXSMohMGTJkFhMIxIQUbbX8u1Xbv
mtfESkzPd7XKQKSNy10tRJtd7aAKveq6vNWBANTI2A0Eu64xNJFk0QSbLRVu5CXOEpBEmldK
JMYy0uRkqIrsFCevMtMChqSGQSwaNsUW0VLRWmBCzMTaE0lLar5rar23xswL1TmQQRJABjM7
bM5dzTBJKYaEghKRMGQJTGAYAhiYiZpEwTJUW+a3li2IihIksJFREWTVjAwCqYNjUW/N9VV/
Navx+MgtlhjjlQ4MoyQ6JtvdSZbW/AtkQpFNo2wZTKT575aWtXzfFGxktAUa2vm9VXeUhoi1
FSbFGmkzFRSe98yVtNtU21vV8kUCNYnz5fK13drUrKtevgNoqkaDETY0a+fPm1mtvnyfPmtt
81tva+DGJArHWt6s27zNIMhpBEDFELRRoookoCiUFrfK9ba+Nbe+Wg0BipKFaNEbGjYqvm9q
18atvm+JfLyaaac2cZZkwswcbqmptkyY2ipKkpNYjQ0k0UzMERBAEJevba9bxQmRUWiRkFtT
1fHytXy18Vje3x0ujbe3l69a11eG0YJPV61e9jQURmaLRGIsFjSerxqrtXm0RtFRGoIL291b
yvXvddIoZFBsQUIWiExpBkxmRMEhZhGClglKlKSGmMaYNM0mMG0JApIMJAyDFMIBBRXurtAB
bJISSRAQSMjBmAIbGyVfxVq37797+Ot6tWQd/dosyrZFhMIsmEWKLCkYexgVopGEe/m0p+TE
lwpGS0xYZItFIyJYUjFIvzPp+n+fr8KHdkSzChPf2T6Hkhn8Z8IoH0kipiKJpBBhFEVNdmhb
hCWgDkJIQULUEMiii4WNtnEAuTgggXBVJIRQIRVALS0tuELS5CKHFQG4ASCJbmBrJNHSEwDW
KJhsARNNhMDdG1XIySCFg5BCEhEEMTCYFmktUXiINxVDll6RtckhiIGkDBFNYAGNmWGSWoZJ
YgORJBETXc3NkhusJgCbBSQRTQvMMzISJaIBey8jMDjbYbCEEVvJjmOZEtUMJICmYSWGSGBu
GwxFA2KoZs1N12EmLswEXYIDhsJppJgW5GSxMil5eQywyFgZLC3g7OXOChZFUgfMKAkEC2BI
BBBbeVu8zbS7xKVqWU3SUUqjeS5u0CkQEO1UCQDBBNhFkhKFexGqJ1eedzS+/KvlJStIHEEb
Kb76uedcRivLvTnfEC76UGAxQjROVLVqNss3JVywMyrBJfNMKMDNBu/F/Htta+NtWtrMpEsy
pEzKFmKFMwSZkVmUJmFUzEkcwNMUnCkbwiS+TFVV0wJVfmqqvEhTrZUMsLMSmMqsZGo2tZb8
XatXLVdySWCIBSimCGIjRRRiNiphQgSjY0atNtqsqWRWCYZKL2O50tHwNLR4rV9WzvIOcqJ7
8Ox2PHRUVZ4EpKD5jr0HQeDQFBwFoVAzzz17+Pr9J8VXKb0dc+fcn3NzVTkv3WYJuvt55Ob5
5ldeVOd+d9Zzvun5ooHIorNoECibEmtFbUVqxzVrcto1WsaysYZYPBqqUeiovGztbR5qlGzv
urbK2eI0XbOLh5qTcbmeszh2tqRcI2eG7cST1w3NzR6Lc3MbOCtLYw6b7999+dvj5+fjey0u
kZXY3JHtxPk5U0AZ1rcs1hV9dU+u0NystrMObeKm+7T9h6HwIPgSCp3auJtJW5XML817aqr9
iEX5norh0cs0fPZduj2oD279TzXDmzxUltOmz5nUIuU2e631OKW+/Q6rx0pJrZ12tHqkan/d
fTzr16+fr9vj7HdvZFazY1HNeXvXqTjMG6FOHDny7mjdpmxppZrzNrgb3tYzN3FeduUaf59f
UCsWNk2Nib817W1u/NvT4mhXzs4sOtyUtHZNDps8rZo8jU0eTVStHmtSU9tmr3ec7+PiOOee
OXyamgsWVFzlUtKLy0lGA2KYlixBzWNYxj2tu7tbXrfMmTan6NXK3LVd9XLbGtT7ffcd3dnd
zlyCAiCSCAxKJIQEUJIb744xB3cwgWiyVWAULIky+zxd3hQ3MV0g2huMd213rGW3rpY1g26T
w0lhmHJCQgp21UFhIpGkDztq6Q7JN+npLIEFSPe2/H1fNutfN9W3u13UbF7mvpr5udcvNb2S
RiXpO1duc2vzq8jFFZDSw8HWVXhaOw0WjqmqR52dZrR2O1ROkqtnPJu/A4elu9tnmbr5dBo9
ClB8CKFKCB6D3fd3nPV/P1eZ5NS5PCok5G95KU5097w8BYIBHh4D0APfCxiMKZlMwjShtGvd
35DlHV3O5ZR0Hai3QilAwt66WBPBB6OzevK25m11LUDVCc6rdoHzoDYhomjWomZWDRZjFWIy
xylN6NxmLKWKwZK2SmJZSlcoDHp1yxkMymZZ3PB9CvQksYgZn7u6XLuuwbkmTmrhZNF3cbTu
3bukXO65koXduIJDGFFjJgsSQiZEImjKQMwGqSNWZKppKYLKwpkrBMVJ5OHm8W3Xh7jydHRZ
w603Wj3I0lGjqqKumjxcPlsfAdHoOg4nTQfCgBQmevlmZ6+Nz3Jucy1Kve6cW5fdj5qSn0qq
Z5DBNrL6VvZah6x1FxT2pZ3fqBp9AHTFmAPIGwFtuSCAdboZq0fF9trWz4mzR0Uvk2tnxEk1
QNHqdNHoctHqNGj4lQ9Xvkc19JPrOT+aeKOIyWW85OXUa7k5wu7bpdV2TizDd2pnabRYa7Ke
Ycd99vfQFWMD2FvtedB6OlRKCJA1aAoMaVqaOlJOl3s5OHadfbkqXD2MA5LnQHAJGgVu6ut8
74a1KVJDA+TiWZmo3d6OK73NFvCsuasQ5UMTfDDW0yuN5d1lUSd9+SHO68y+c9nyi4QSESew
9PsCj4NRo72qktGLDwppaO8lNGjstRo95pTR8DD4qTb26M6eN8ZvfG08ykhibLe7ucy6ebmk
swgwCTpiQSGwCQEelZAqMootQ2KBOUE0ylMjbfNvw5aS5e93pL7339cfSeu8rnu7LzmQrnmu
Xd1k3rF05qwaO51gWZSysqsXqurIrqSC0d2g+fZuPmsvw8KQ42aGlDWklMzFQ8mHCudKmWpc
ggIEliQzUmIet25aJLlyiyZDLEkEhJIFodwZAHovoA6QOqQK8oyy/W31XroY1Pm+q73anfK8
vpV1wORpbcxrXZt+230YaK/av1v2NHVa0dbVaOqaTRhh2ohq0eLQ0fE1aO4+u6k2eFQ4fl+/
MzMzt8+PjXrWt81vnOa+R+h7j7H7dnD6f7P1PsfY/T8Th/c8H28n/sO59jDXr/x9z+Z1Oh3P
2F+J9z7vv+f0PwL/4u5IpwoSAncKFeA=
--------------060800070802080106030001--
0
Juan
10/17/2015 2:22:09 PM
On 10/17/15, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:
> Am 17.10.2015 06:55, schrieb DJ Delorie:
>>> So guess we should actually release 2.05 now.
>>
[...]
> a) now it is 15:45 here in germany.  I will wait until 21:00 (local time)
>    to see if Ozkan has committed his DXE module patch as presented in:
>
> <http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/10/04/13:58:46>
>    I do not want to apply it because I do not know if that is really the
>    final version.  If I see that he has not committed the patch, then this
>    feature will definitively __NOT__ be part of the 205 release.

I never got any response, so I am still waiting.  The patch is final
as far as I would implement it.  So, here I ask:
- Should I apply dxe patch to CVS HEAD?
- Should I apply dxe patch to CVS v2_05_1 branch?

--
O.S.
0
Ozkan
10/17/2015 2:47:45 PM
On Saturday, October 17, 2015 at 4:47:54 PM UTC+2, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
> On 10/17/15, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via
> djgpp@delorie.com] <djgpp@delorie.com> wrote:
> > Am 17.10.2015 06:55, schrieb DJ Delorie:
> >>> So guess we should actually release 2.05 now.
> >>
> [...]
> > a) now it is 15:45 here in germany.  I will wait until 21:00 (local time)
> >    to see if Ozkan has committed his DXE module patch as presented in:
> >
> > <http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/10/04/13:58:46>
> >    I do not want to apply it because I do not know if that is really the
> >    final version.  If I see that he has not committed the patch, then this
> >    feature will definitively __NOT__ be part of the 205 release.
> 
> I never got any response, so I am still waiting.  The patch is final
> as far as I would implement it.  So, here I ask:
> - Should I apply dxe patch to CVS HEAD?
> - Should I apply dxe patch to CVS v2_05_1 branch?
> 
> --
> O.S.

Both branches.

Regards,
Juan M. Guerrero
0
Juan
10/17/2015 5:20:11 PM
On 10/17/15, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:
> On Saturday, October 17, 2015 at 4:47:54 PM UTC+2, Ozkan Sezer
> (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
>> On 10/17/15, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via
>> djgpp@delorie.com] <djgpp@delorie.com> wrote:
>> > Am 17.10.2015 06:55, schrieb DJ Delorie:
>> >>> So guess we should actually release 2.05 now.
>> >>
>> [...]
>> > a) now it is 15:45 here in germany.  I will wait until 21:00 (local
>> > time)
>> >    to see if Ozkan has committed his DXE module patch as presented in:
>> >
>> > <http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/10/04/13:58:46>
>> >    I do not want to apply it because I do not know if that is really
>> > the
>> >    final version.  If I see that he has not committed the patch, then
>> > this
>> >    feature will definitively __NOT__ be part of the 205 release.
>>
>> I never got any response, so I am still waiting.  The patch is final
>> as far as I would implement it.  So, here I ask:
>> - Should I apply dxe patch to CVS HEAD?
>> - Should I apply dxe patch to CVS v2_05_1 branch?
>>
>> --
>> O.S.
>
> Both branches.
>
> Regards,
> Juan M. Guerrero
>

OK, applied to both branches.  Thanks.

--
O.S.
0
Ozkan
10/17/2015 6:16:09 PM
On 10/17/15, Ozkan Sezer <sezeroz@gmail.com> wrote:
> On 10/17/15, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via
> djgpp@delorie.com] <djgpp@delorie.com> wrote:
>> On Saturday, October 17, 2015 at 4:47:54 PM UTC+2, Ozkan Sezer
>> (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
>>> On 10/17/15, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via
>>> djgpp@delorie.com] <djgpp@delorie.com> wrote:
>>> > Am 17.10.2015 06:55, schrieb DJ Delorie:
>>> >>> So guess we should actually release 2.05 now.
>>> >>
>>> [...]
>>> > a) now it is 15:45 here in germany.  I will wait until 21:00 (local
>>> > time)
>>> >    to see if Ozkan has committed his DXE module patch as presented in:
>>> >
>>> > <http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/10/04/13:58:46>
>>> >    I do not want to apply it because I do not know if that is really
>>> > the
>>> >    final version.  If I see that he has not committed the patch, then
>>> > this
>>> >    feature will definitively __NOT__ be part of the 205 release.
>>>
>>> I never got any response, so I am still waiting.  The patch is final
>>> as far as I would implement it.  So, here I ask:
>>> - Should I apply dxe patch to CVS HEAD?
>>> - Should I apply dxe patch to CVS v2_05_1 branch?
>>>
>>> --
>>> O.S.
>>
>> Both branches.
>>
>> Regards,
>> Juan M. Guerrero
>>
>
> OK, applied to both branches.  Thanks.
>
> --
> O.S.
>

And if it helps, here is my build from the unmodified v2_05_1 branch:
http://uhexen2.sf.net/tmp/v2_05_1/
The packages were built with gcc-3.4.6 and binutils-2.25.1-r2 using a
linux-i686-to-djgpp cross-toolchain.

(If they aren't needed, tell me so I can delete them to save space.)

--
O.S.
0
Ozkan
10/17/2015 6:42:16 PM
On Saturday, October 17, 2015 at 8:42:31 PM UTC+2, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
> On 10/17/15, Ozkan Sezer <sezeroz@gmail.com> wrote:
> > On 10/17/15, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via
> > djgpp@delorie.com] <djgpp@delorie.com> wrote:
> >> On Saturday, October 17, 2015 at 4:47:54 PM UTC+2, Ozkan Sezer
> >> (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
> >>> On 10/17/15, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via
> >>> djgpp@delorie.com] <djgpp@delorie.com> wrote:
> >>> > Am 17.10.2015 06:55, schrieb DJ Delorie:
> >>> >>> So guess we should actually release 2.05 now.
> >>> >>
> >>> [...]
> >>> > a) now it is 15:45 here in germany.  I will wait until 21:00 (local
> >>> > time)
> >>> >    to see if Ozkan has committed his DXE module patch as presented in:
> >>> >
> >>> > <http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/10/04/13:58:46>
> >>> >    I do not want to apply it because I do not know if that is really
> >>> > the
> >>> >    final version.  If I see that he has not committed the patch, then
> >>> > this
> >>> >    feature will definitively __NOT__ be part of the 205 release.
> >>>
> >>> I never got any response, so I am still waiting.  The patch is final
> >>> as far as I would implement it.  So, here I ask:
> >>> - Should I apply dxe patch to CVS HEAD?
> >>> - Should I apply dxe patch to CVS v2_05_1 branch?
> >>>
> >>> --
> >>> O.S.
> >>
> >> Both branches.
> >>
> >> Regards,
> >> Juan M. Guerrero
> >>
> >
> > OK, applied to both branches.  Thanks.
> >
> > --
> > O.S.
> >
> 
> And if it helps, here is my build from the unmodified v2_05_1 branch:
> http://uhexen2.sf.net/tmp/v2_05_1/
> The packages were built with gcc-3.4.6 and binutils-2.25.1-r2 using a
> linux-i686-to-djgpp cross-toolchain.
> 
> (If they aren't needed, tell me so I can delete them to save space.)
> 
> --
> O.S.

The packages can be delete.

Regards,
Juan M. Guerrero
0
Juan
10/18/2015 7:05:51 PM
On 10/17/2015 10:15 AM, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
> On 10/17/2015 07:55 AM, DJ Delorie wrote:
>>> So guess we should actually release 2.05 now.
>> While it's ultimately up to you and Juan, I agree :-)
>>
> Especially when nmalloc is out of my list of suspects now as linking with old DJGPP v2.03
> malloc and calloc do not fix the problem.
>
I mentioned Windows Vista in this thread only because I had similar errors with DJGPP v2.03p2
when building GCC (much more seldom than with recent tests with Windows 10). There are no
related problems with DJGPP 2.05 and Windows Vista Business. For example built
yesterdays SVN version of gcc trunk (gcc-6.0.0-20151018 experimental) for DJGPP v2.05
without any problems on Windows Vista. So it seems to be rather good probability that we'll
have at least gcc-6.0.0 port for DJGPP when GCC next version will be released (no Ada support
tried though)

Andris

0
Andris
10/19/2015 4:13:12 AM
> AFAIK Microsoft has clearly state that they are no longer interested in 
> suporting MS-DOS applications on their OSs.
> And all DJGPP programs are MS-DOS applications that require a full 
> functional
> DOS environment to work flawlessly, so IMO it becomes very unlikely that 
> the
> goal of getting DJGPP working on modern Windows operating systems can ever 
> be
> achived.  I am not opposing on trying to get DJGPP working on Windows 10 
> or
> similar OS but in consideration of the fact of the small amount of DJGPP 
> users
> and the even smaller amount of skilled DJGPP developers really familiar 
> with
> DJGPP internals and Windows internals, this will take at least a couple of 
> months
> more, probably it will take years.  IMO, an attempt to get DJGPP working 
> on
> Windows 10 or similar operating systems shall be postponed until 205 has 
> been
> released.  The over the years vanishing group of DJGPP users do not 
> deserve to
> wait until the end of days for this release.  I really think that we shall 
> take
> seriously user questions like this one:


It's obvious that MS has no intention to bring NTVDM back to its glory.
But sticking to Windows XP as the "last good OS" is as slow path to death of 
DJGPP.
If there is to be any future of DJGPP (a very limited one, but still a 
future), the project has to embrace what is still alive: DOSBox and FreeDOS. 
Full compatibility may require a cooperation with those projects' 
developers, and fixing some things on their sides too, but at least those 
*can* be fixed, unlike Windows.

A mid-term goal should be a successful build of DJGPP/gcc/binutils on 
FreeDOS (as I understand it doesn't work right now).



-- 
Wiktor S.

0
Wiktor
10/19/2015 6:26:54 PM
I agree with Wiktor.  FD (or some other DOS) ought to be goal somewhere.

If, however, an XP-based OS remains a hard requirement, a guide for
Windows POSReady 2009 [0][1][2] could be developed.  It seems to be
the last XP-based OS available until 2019.


[0] https://en.wikipedia.org/wiki/Windows_Embedded_Industry#Releases
[1] http://www.microsoft.com/windowsembedded/en-us/downloads.aspx
[2] https://support.microsoft.com/en-us/lifecycle?p1=14086


On Mon, Oct 19, 2015 at 11:26 AM, Wiktor S. (wswiktorSP@Mpoczta.fm)
[via djgpp@delorie.com] <djgpp@delorie.com> wrote:
>> AFAIK Microsoft has clearly state that they are no longer interested in
>> suporting MS-DOS applications on their OSs.
>> And all DJGPP programs are MS-DOS applications that require a full
>> functional
>> DOS environment to work flawlessly, so IMO it becomes very unlikely that
>> the
>> goal of getting DJGPP working on modern Windows operating systems can ever
>> be
>> achived.  I am not opposing on trying to get DJGPP working on Windows 10
>> or
>> similar OS but in consideration of the fact of the small amount of DJGPP
>> users
>> and the even smaller amount of skilled DJGPP developers really familiar
>> with
>> DJGPP internals and Windows internals, this will take at least a couple of
>> months
>> more, probably it will take years.  IMO, an attempt to get DJGPP working
>> on
>> Windows 10 or similar operating systems shall be postponed until 205 has
>> been
>> released.  The over the years vanishing group of DJGPP users do not
>> deserve to
>> wait until the end of days for this release.  I really think that we shall
>> take
>> seriously user questions like this one:
>
>
>
> It's obvious that MS has no intention to bring NTVDM back to its glory.
> But sticking to Windows XP as the "last good OS" is as slow path to death of
> DJGPP.
> If there is to be any future of DJGPP (a very limited one, but still a
> future), the project has to embrace what is still alive: DOSBox and FreeDOS.
> Full compatibility may require a cooperation with those projects'
> developers, and fixing some things on their sides too, but at least those
> *can* be fixed, unlike Windows.
>
> A mid-term goal should be a successful build of DJGPP/gcc/binutils on
> FreeDOS (as I understand it doesn't work right now).
>
>
>
> --
> Wiktor S.
>
0
Louis
10/19/2015 8:16:58 PM
> If, however, an XP-based OS remains a hard requirement, a guide for
> Windows POSReady 2009 [0][1][2] could be developed.  It seems to be
> the last XP-based OS available until 2019.

POSReady 2009 is a version of XP just like Home, Professional, Media Center 
and Tablet PC, so everything that works on XP should work on POSReady...

-- 
Wiktor S.

0
Wiktor
10/20/2015 4:10:13 PM
On 10/19/2015 2:26 PM, Wiktor S. wrote:
> It's obvious that MS has no intention to bring NTVDM back to its glory.
> But sticking to Windows XP as the "last good OS" is as slow path to
> death of DJGPP.
> If there is to be any future of DJGPP (a very limited one, but still a
> future), the project has to embrace what is still alive: DOSBox and
> FreeDOS. Full compatibility may require a cooperation with those
> projects' developers, and fixing some things on their sides too, but at
> least those *can* be fixed, unlike Windows.
>
> A mid-term goal should be a successful build of DJGPP/gcc/binutils on
> FreeDOS (as I understand it doesn't work right now).

I have no problem with this; but I would prefer (if it doesn't get too 
out of hand) to maintain current compatibility with XP and MS-DOS with 
lfn (at least with the smaller projects); but FreeDOS and 
cross-compilers to be guaranteed.

Frank

0
Frank
10/20/2015 4:37:55 PM
On Monday, October 19, 2015 at 8:26:54 PM UTC+2, Wiktor S. wrote:
> > AFAIK Microsoft has clearly state that they are no longer interested in 
> > suporting MS-DOS applications on their OSs.
> > And all DJGPP programs are MS-DOS applications that require a full 
> > functional
> > DOS environment to work flawlessly, so IMO it becomes very unlikely that 
> > the
> > goal of getting DJGPP working on modern Windows operating systems can ever 
> > be
> > achived.  I am not opposing on trying to get DJGPP working on Windows 10 
> > or
> > similar OS but in consideration of the fact of the small amount of DJGPP 
> > users
> > and the even smaller amount of skilled DJGPP developers really familiar 
> > with
> > DJGPP internals and Windows internals, this will take at least a couple of 
> > months
> > more, probably it will take years.  IMO, an attempt to get DJGPP working 
> > on
> > Windows 10 or similar operating systems shall be postponed until 205 has 
> > been
> > released.  The over the years vanishing group of DJGPP users do not 
> > deserve to
> > wait until the end of days for this release.  I really think that we shall 
> > take
> > seriously user questions like this one:
> 
> 
> It's obvious that MS has no intention to bring NTVDM back to its glory.
> But sticking to Windows XP as the "last good OS" is as slow path to death of 
> DJGPP.
> If there is to be any future of DJGPP (a very limited one, but still a 
> future), the project has to embrace what is still alive: DOSBox and FreeDOS. 
> Full compatibility may require a cooperation with those projects' 
> developers, and fixing some things on their sides too, but at least those 
> *can* be fixed, unlike Windows.
> 
> A mid-term goal should be a successful build of DJGPP/gcc/binutils on 
> FreeDOS (as I understand it doesn't work right now).
> 
> 
> 
> -- 
> Wiktor S.


I think that no one denies that with Vista DJGPP has reached the end
of the road on Microsoft operating systems.

Only for the record: with the 2.05 release it is possible to compile the
repository code without any difficulties.  On MSDOS-6.22 with DOSLFN 0.41c
it took around 7 hours.  On FreeDOS 1.0 (not FreeDOS 1.1) without LFN driver
it tooks 3:39 hours.

Every thing else will become really difficult due to different issues in
FreeDOS and other issues in certain DJGPP ports.  May be there are also
issues in libc.a itself.  I do not know if every code snippet committed
to the repository has really been checked to work on MS-DOS too instead.
I doubt that the vast majority of the developers still have access to
some MS-DOS version.

Regards,
Juan M. Guerrero
0
Juan
10/20/2015 5:52:57 PM
On 10/20/2015 1:52 PM, Juan Manuel Guerrero wrote:
> Every thing else will become really difficult due to different issues in
> FreeDOS and other issues in certain DJGPP ports.  May be there are also
> issues in libc.a itself.  I do not know if every code snippet committed
> to the repository has really been checked to work on MS-DOS too instead.
> I doubt that the vast majority of the developers still have access to
> some MS-DOS version.

I am compiling code mostly on XP and sometimes smaller programs on DOS 7 
(i.e. Windows 98SE Boot Disk) and would like to be able to compile such 
things on these target systems instead of relying on Linux to compile my 
DOS programs.

Frank
0
Frank
10/20/2015 6:20:34 PM
On 10/20/15, Frank H. Sapone (fhsapone@windstream.net) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:
> On 10/20/2015 1:52 PM, Juan Manuel Guerrero wrote:
>> Every thing else will become really difficult due to different issues in
>> FreeDOS and other issues in certain DJGPP ports.  May be there are also
>> issues in libc.a itself.  I do not know if every code snippet committed
>> to the repository has really been checked to work on MS-DOS too instead.
>> I doubt that the vast majority of the developers still have access to
>> some MS-DOS version.
>
> I am compiling code mostly on XP and sometimes smaller programs on DOS 7
> (i.e. Windows 98SE Boot Disk) and would like to be able to compile such
> things on these target systems instead of relying on Linux to compile my
> DOS programs.
>

There is always the option of cross-compile to djgpp from windows:
i.e. mingw/mingw-w64 to djgpp cross-compilation, both for building
djgpp itself and also dos-targeting programs.  The djgpp source
should be pretty much ready for such a scenario (of course we can
have a closer look.)

And IMHO, major focus of djgpp development must be functioning
properly on real DOS operating systems instead of proper function
under ntvdm or emulators / virtual machines.
0
Ozkan
10/20/2015 6:55:30 PM
On 10/20/2015 2:55 PM, Ozkan Sezer (sezeroz@gmail.com) [via 
djgpp@delorie.com] wrote:
> And IMHO, major focus of djgpp development must be functioning
> properly on real DOS operating systems instead of proper function
> under ntvdm or emulators / virtual machines.

Agreed.

I'm okay with Windows cross-compiling, as long as it isn't some 
convoluted mess to do so.

Frank

0
Frank
10/20/2015 9:10:48 PM
> There is always the option of cross-compile to djgpp from windows:
> i.e. mingw/mingw-w64 to djgpp cross-compilation, both for building
> djgpp itself and also dos-targeting programs.  The djgpp source
> should be pretty much ready for such a scenario (of course we can
> have a closer look.)

There is a script to build a mingw to djgpp cross-compiler on github, among 
with various pre-built binaries:
https://github.com/andrewwutw/build-djgpp/releases

I haven't checked it. I only needed ld.exe from this package for use with 
Free Pascal.


-- 
Wiktor S.

0
Wiktor
10/22/2015 12:55:06 PM
--089e01182dc49328b00522b222f6
Content-Type: text/plain; charset=UTF-8

Andrew Wu's script works great. I used it to cross compile lz4 for DOS.

-L

On Thursday, October 22, 2015, Wiktor S. (wswiktorSP@Mpoczta.fm) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:

> There is always the option of cross-compile to djgpp from windows:
>> i.e. mingw/mingw-w64 to djgpp cross-compilation, both for building
>> djgpp itself and also dos-targeting programs.  The djgpp source
>> should be pretty much ready for such a scenario (of course we can
>> have a closer look.)
>>
>
> There is a script to build a mingw to djgpp cross-compiler on github,
> among with various pre-built binaries:
> https://github.com/andrewwutw/build-djgpp/releases
>
> I haven't checked it. I only needed ld.exe from this package for use with
> Free Pascal.
>
>
> --
> Wiktor S.
>
>

--089e01182dc49328b00522b222f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Andrew Wu&#39;s script works great. I used it to cross compile lz4 for DOS.=
<div><br></div><div>-L<span></span><br><br>On Thursday, October 22, 2015, W=
iktor S. (wswiktorSP@Mpoczta.fm) [via <a href=3D"mailto:djgpp@delorie.com">=
djgpp@delorie.com</a>] &lt;<a href=3D"mailto:djgpp@delorie.com">djgpp@delor=
ie.com</a>&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
There is always the option of cross-compile to djgpp from windows:<br>
i.e. mingw/mingw-w64 to djgpp cross-compilation, both for building<br>
djgpp itself and also dos-targeting programs.=C2=A0 The djgpp source<br>
should be pretty much ready for such a scenario (of course we can<br>
have a closer look.)<br>
</blockquote>
<br>
There is a script to build a mingw to djgpp cross-compiler on github, among=
 with various pre-built binaries:<br>
<a href=3D"https://github.com/andrewwutw/build-djgpp/releases" target=3D"_b=
lank">https://github.com/andrewwutw/build-djgpp/releases</a><br>
<br>
I haven&#39;t checked it. I only needed ld.exe from this package for use wi=
th Free Pascal.<br>
<br>
<br>
-- <br>
Wiktor S.<br>
<br>
</blockquote></div>

--089e01182dc49328b00522b222f6--
0
Louis
10/22/2015 2:16:02 PM
Reply:

Similar Artilces:

Porting Windows 32 bit driver to 64 bit Windows
Hi, I have a WDM driver working in 32 bit windows. I need to port it to 64 bit world. I have started with all the basics but the driver build settings are failing. I have installed WinDDK . Its not working. Also what are the steps necessary to port the driver . I am aware of the address space for 64 bit and its increase in size for pointers. The build settings work fine on 32 bit , but when i try to build it for 64 bit it fails. I am building the driver on 32 Bit windows XP. Are there any switches to be added in order to build. It will be very helpful if someone informs about the...

[News] [Rival] Windows Vista Sales + Windows Vista Upgrades = Windows XP
Vista downgrading: What are your rights? ,----[ Quote ] | Talk about a catch 22. Did you know that in order to be allowed to downgrade | Vista to XP on a new computer, Microsoft expects you to have one of the more | expensive editions of Windows Vista that most OEMs don’t even put on their | machines. It’s true. Have a look at this official Microsoft one-sheet | explaining the intricacies of downgrading from Vista that’s come bundled with | a new PC. | | You’d have to add $180 to the price of a Dell Inspiron 530 in order to have | the right to use XP instead of Vista. `---- http...

How to tell if a program compiled as 32-bit or 64-bit? (Windows Vista 64)
I think I have finally gotten my Visual C++ Express 2008 to use the 64-bit compiler in the Windows 7 SDK. I THINK! But I want to make sure. I've compiled some programs with the 'target platform' set to x64 in VC Express, but how do I tell if they really compiled into AMD64 code? Thanks, Roy "Bad Roy" <AlaBadRoy@yahoo.com> wrote in message news:e1t5e51mvn3hd721l4or8l1qr2vjiff069@4ax.com... > I think I have finally gotten my Visual C++ Express 2008 to > use the 64-bit compiler in the Windows 7 SDK. I THINK! But I want to > make sure. I've co...

64-bit Windows Vista is faster than 32-bit Vista
http://64-bit-computers.com/windows-vista-32-bit-vs-64-bit-benchmark.html Interestingly enough alot of hardware sites are recommending using 32 bit Vista, even though the 64-bit Vista is faster. I just don't get it. People who will hook their computers up to water hoses and refrigerant balk at a 10 percent increase in performance. Of course theer are caveats to 64-bit Vista: 1) Driver support is not quite as good as 32-bit. Especially for devices like printers, scanners, cameras, etc. 2) Vista-64 requires signed drivers. The rationale is that Microsoft wants more control over...

Windows 10, AKA Windows 8.2, AKA Windows Nein!
<grin> -- Rincewind formed a mental picture of some strange entity living in a castle made of teeth. It was the kind of mental picture you tried to forget. Unsuccessfully. -- Terry Pratchett, "The Light Fantastic" Chris Ahlstrom wrote: > <grin> I think you hit on why M$ avoided using 9 after the Windows name. LOL On Tuesday, November 11, 2014 6:01:58 AM UTC-5, Chris Ahlstrom wrote: > <grin> Re: Windows 10, AKA Windows 8.2, AKA Windows Nein! Moi is seriously considering buying a brand new Windows 8.1 computer with a large tou...

Windows Vista two windows
Hello, Is there any way to avoid a second black window when using emacs under Windows Vista? Thanks, Andr=E9 Luiz AndreLTR <andreltramos@gmail.com> writes: > Is there any way to avoid a second black window when using emacs under > Windows Vista? What version of Emacs are you using and where from? I downloaded the one linked from the GNU Emacs FAQ and when running "runemacs.exe" it works fine for me without window. - Jerome Hello, It works this way thanks! Sorry for the double post. Sincerely, Andr=E9 Luiz On 28 dez, 17:11, Jerome Baum <em...@jeromebaum.co...

E_RE0006_STARTUP_RMCMD_OBJ error in Windows 32 Bit of Ingres 10
This morning I did a new install of 32 bit Ingres 10 on Win XP using a domain account of '??????\kyle.hanson', of which the ?????? would be replaced by our company domain. The install completed successfully, but when I try to start it, the remote command server doesn't start. I get this error: E_RE0006_STARTUP_RMCMD_OBJ Cannot access the RMCMD objects. The SQL error code was -30100. Please help. -- kyle.hanson@resolvecorporation.com ------------------------------------------------------------------------ kyle.hanson@resolvecorporation.com's Profile: http:...

Microsoft Forces Windows 10 Downloads Onto Windows 7 And Windows 8
The saga continues. Following news that Windows 10 automatically downloads onto Windows 7 and Windows 8 for users who choose to upgrade, Microsoft MSFT +0.00% has now confirmed it has taken things one serious step further: Windows 10 will now download on computers even when users chose NOT to upgrade. This somewhat shocking development was discovered by The Inquirer when a reader reported Windows 10 had been downloaded onto their computer despite the fact they expressly declined the opportunity to upgrade: �The symptoms are repeated failed �Upgrade to Windows 10' in ...

Root Window & Windows within Windows
Even (on 98) if you replace the shell explorer.exe you are left with the root window. Explorer.exe does a good job of adding content to the root window. It places icons on your desktop and gives you a task bar. The only ability I am aware of that programmers have to add content to the root window (aside from replacing explorer.exe), is with Active Desktop. I feel that active desktop should be a program we can write ourselves. We should be able to write our own programs that are drawn directly to the root window, just like active desktop windows are. Even when you replace ...

file server Windows 2008 32-bit <->Windows 7 64 bit , slow DBF access
Users complain that my programs, compiled with HB 2.0, 32-bit, DBF/NTX, run significantly slower on new computers with Windows 7 64 bit than on old ones with XP. DBF's are stored on Windows 2008 (not R2), 32-bit. There are another PC's with Win 7 32-bit in the same network, no speed degradation. Any suggestions? Dear ktos: On Monday, April 8, 2013 8:56:56 AM UTC-7, ktos wrote: .... > Users complain that my programs, compiled with HB > 2.0, 32-bit, DBF/NTX, run significantly slower on > new computers with Windows 7 64 bit than on old > ones with XP. DB...

Windows XP 64-bit runs 32-bit apps 8% faster than Windows XP on exact same AMD64 box
Bob Muglia: One thing we've found is that 32-bit applications run better on the 64-bit OS than they do on 32-bits. Just adding a 64-bit processor and the 64-bit OS changes everything. Paul: Now what are you comparing there? Are these machines running the same clock speed... Bob Muglia: Same everything. Same chips, same everything. We run apps on 32-bit Windows, and then take those same apps and run them on 64-bit Windows, and you'll get about an 8 percent performance improvement on average. http://www.winsupersite.com/showcase/muglia_winserver.asp On Thu, 06 Jan 2005 15:32:29 +010...

Out of memory error compiling Mesa 6.4.2 in Windows 7 32-bit
Hello, I normally compile all my projects on Windows XP SP3 but opted to try it on my newer, faster computer that has Windows 7 32-bit. When compiling a large project like Mesa 6.4.2 it gets to fxtris.c in the project then bombs out with: cc1.exe: out of memory allocating 4072 bytes after a total of 27307024 bytes. This is the same DJGPP directory copied over from Windows XP SP3, where it compiles fine there. Is this a known issue with DJGPP 2.05? I am using GCC3.4.6 and Binutils 2.25 (reported from running ar -v). Frank On 09/12/2015 11:31 PM, emoaddict15@gmail.com [via djg...

window-handlers on windows
hi (this is my first post to this ng; so if it is the wrong ng, please direct me to the one i need...) my problem not necessarily bound to C++ (but could also be C), but since my application is in C++, i post it here. i want to draw from application A into a window that has been created by an application B (in my case: i want to render an openGL-scene into a a browser-window) under linux i can get a handle of type "Window" from the Xserver, into which i can draw (assumed that i have permissions) under windows the only such handle i have found is HWND, which is a pointer to a ...

windows safari and windows
Testing locally on an Win XP box with the safari pop up blocker disabled: window.close(); will close the window without warning even though the window was not opened by javascript. win = window.open("test.htm","foo");//, str); alert(win); does not open a new window and the value displayed by the alert is "undefined" (shouldn't it be "null" if there was a problem???). Also safari's activity window doesn't show any problems encountered. If I put a link on the page <a href="test.htm" target="_blank">click here<...

Web resources about - Random compile errors under WIndows (32 bit Windows Vista and Windows 10) - comp.os.msdos.djgpp

Compile (publisher) - Wikipedia, the free encyclopedia
Compile was a Japanese videogame developer, most notable for having developed the Puyo Puyo series, based on their Madou Monogatari franchise, ...

Information Is Power: Facebook Develops ThreatData To Compile Data On Web Threats
Part of being able to combat malware, phishing, and other online threats is gathering and consolidating as much data on those threats as possible, ...

Credit Suisse compiles yuan winners and losers list: report
... the lowers. A list of Australian winners and losers from the decision by China’s government to devalue the renminbi has reportedly been compiled ...

Beijing residents compile own death toll in flooding
Beijing residents fed up with a lack of official updates are compiling their own death tolls for last weekend's deadly floods in the capital, ...

New report compiles 25 years of UFO sightings in Canada
A Winnipeg group called Ufology Research has compiled and analyzed reported sightings of UFOs across Canada over the last 25 years.

China's nat'l library to compile book on Diaoyu Islands
China's nat'l library to compile book on Diaoyu Islands People's Daily Online ... States, Australia and the United Kingdom. The book is aimed ...

Googlers compile holiday search tips in rap video to help Santa with flight
Google is in full holiday swing (what, you haven't heard?). They just posted, on YouTube, a rap video that was put together by its employees, ...

Popular Dating Site Compiles 15 Stupid Reasons To Date A Lawyer
A new listicle describes a really horrible person to date and then says, “we think lawyers are probably this awful, go date them!” Continue ...

Author Compiles Lively L.A. Times History Lesson
Long before Eli Broad , Rupert Murdoch and people willing to pay $140 million for the Las Vegas Review-Journal, there was Harrison Gray Otis ...

Japan, China compile written pledge to improve ties ahead of summit
Japan and China reached a rare written agreement on Nov. 7 to improve relations strained by a territorial dispute over the Senkaku Islands in ...

Resources last updated: 1/25/2016 4:13:08 AM