🚀 go-pugleaf

In article <445@usl.usl.edu>, pcb@usl.usl.edu (Peter C. Bahrs) writes:
> 
> 1) Zortech is not releasing and hooks into MS Windows with its C++ compiler.
                 ^
	do you mean "now"?

> 6) It appears that a port from a MS Windows environment to Presentation
> Manager will be about 60% straightforward & about 40% re-thinking/re-coding!

This week's PC Week (page 1) reports that Micrografx may come out with a
"tool kit that converts Windows applications to OS/2 Presentation Manager
format without requiring modifications to the source code".  We'll see...

-- 
Brian R. Lair            NCR Corporation, E&M Wichita, Advanced Development
 Brian.Lair@Wichita.NCR.COM
 <{ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!brian.lair>
 <{ucsd,pyramid,nosc.ARPA}!ncr-sd!ncrwic!brian.lair>

In article <358@enint.Wichita.NCR.COM>, blair@enint.Wichita.NCR.COM (Brian Lair) writes:
> In article <445@usl.usl.edu>, pcb@usl.usl.edu (Peter C. Bahrs) writes:
> > 
> > 1) Zortech is not releasing and hooks into MS Windows with its C++ compiler.
>                  ^
> 	do you mean "now"?

After talking with the author of Zortech's C++ compiler and several
representatives from Zortech, they message I received is that they are not
working on a MS windows version at all. 

I have read that Zortech was working on this product (in news) but they
dismissed it.

In article <445@usl.usl.edu>, pcb@usl.usl.edu (Peter C. Bahrs) writes:

# 3) Consider what happens in MS Windows when moving segments (i.e. pointers
# are changed, memory compacted, etc).  If your code is developed correctly
# everything is fine.
# So how are you doing IO???  Note that all of the C libraries are
# C libraries.  So if you call a stdio function, like scanf or printf and
# windows decides to move these routines, what happens.  Well apparently
# some of these routines use internall buffers and the pointers do not
# get updated like MS Windows pointers and ker-blang, fatal error of
# some kind. This 'syndrome' seems to occur with any C routine that may
# have pointers and especially when memory is low..

This problem arises when you try to use buffered I/O, and the C library 
code mallocs a buffer, which Windows translates to a LocalAlloc; Windows
may move your data segment under these conditions, invalidating any 
far pointers into it. 

A couple of work-arounds:

1.  Don't use buffered I/O (fopen, fwrite, etc), use the low-level
open, write, etc instead.  These are safe.  This means that you can't
use fprintf, but you can use sprintf to format a string into a buffer, 
then use write to write it to a file.

2.  Before doing any buffered I/O, use the Microsoft C Library's
setbuf() call to set up your own I/O buffer.  Then, the C library won't
try to malloc one, and the problem you mention will go away.

We've used both of these approaches with no problems, after having
lots of problems trying to do buffered I/O without the setbuf call.

3.  I haven't tried this, but Petzold describes some undocumented
Windows file I/O functions on pages 455-458 of _Programming Windows_.


-- 

---------
Matt Meighan
matt@nbires.nbi.com (nbires\!matt)