We have a special case where we write documents out by appending data to the
end of the file. We do this in our Unix environments by using the C calls
with open, and write.

I have tried to make this happen in D3NT, which I have heard works. I am on
7.4.7, so that might be an issue (if this only works in 7.5.x).

Something simple like:

fl.nme = 'c:\temp\test.dat'
fd = %open(fl.nme,o$rdwr)
tbl = 'Single Test Line ':char(10)
rc=%write(fd, tbl, len(tbl) )
%close( fd )

Where I have set o$rdwr to different values. Although I don't know where to
find the values of this variable for windows environment. I'd like the
o$rdwr to really be o$append.

"Jt" <jtillia (AT) acspg (DOT) com> wrote in
news:12nrekbd2ju1c6c (AT) corp (DOT) supernews.com:

From the 7.5 Ref Man.

FlashBASIC C Functions
C Functions Overview
C functions can be called from a FlashBASIC program or subroutine in D3
UNIX implementations using a syntax similar to that of normal C.


This leads me to believe that they do not work in D3/NT. I'd be
interested in anyone that has them working.


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Hi
You have run into one of the best ideas with the worst
documentation/implementation in D3. Some genius a few years back removed
the NT add in file and buried them in a file called Unix.h. You need
001 $OPTIONS EXT
002 INCLUDE DM,BP,UNIX.H FCNTL.H;* Yes this does apply to NT
Then comes the tricky bit, not all the commands apply in NT. You can deduce
it from the docs in most cases however be cautious and test little bits at a
time.
I had it working in 7.4.4 so good luck. Make sure you have the correct
COMPILE options this does not work with the BASIC verb.
Peter McMurray

"Jt" <jtillia (AT) acspg (DOT) com> wrote

On Mon, 11 Dec 2006 15:07:37 -0500, "Jt" <jtillia (AT) acspg (DOT) com> wrote:


Someone posted this snippet some time ago - it is a good example of
how these routines work:

include dm,bp,unix.h fcntl.h
open "dos:c:/" to cfile
open "ghcbp" to workfile
bf=""
write bf on cfile,"dosfile"
close cfile
fd=%open("c:/dosfile",O$RDWR)
select workfile
wtext=""
loop
readnext id else exit
readv rec from workfile,id,1 then
wtext=rec<1>:char(13):char(10)
nbytes=len(wtext)
if %write(fd,wtext,n_bytes) < n_bytes then
print "Error writing"
end
end
repeat
if %close(fd) # 0 then
print "Error closing the file"
end


Compile this using the COMPILE verb eg

COMPILE BP TESTONE (FO

This works like a charm on NT although in some older releases (< 7.2)
there were a few funnies.

Many thanks to the original poster and apologies for having lost your
name.

Dave

"Excalibur" wrote:

What "NT add in file"? My C functions have always used Unix.h. Here
is a segment from one of my progs.

$options ext
cfunction socket.builtin
include dm,bp,includes sysid.inc
include dm,bp,unix.h socket.h
include dm,bp,unix.h fcntl.h
include dm,bp,unix.h errno.h
include dm,bp,unix.h signal.h

I understand the confusion and agree that it's a paradox, but would
you prefer to have to modify your code depending on the deployment
platform? The fcntl.h code includes proper values for all platforms,
*nix and nt. The code being discussed here should work with just a
recompile between *nix and NT (except that Jesse is hardcoding values,
see below). If the location of the include items change between
platforms, that wouldn't be the case and people would get bent all out
of shape.

As I recall there are very few exceptions and they all relate to
sockets, not file IO. %recv vs %read, %send vs %write, and
%closesocket vs %close. Simple code gets around this - it's worked
for so long without error that I forgot how it works anymore.


Despite my "please check again" inquiries with RD, I've been
re-re-assured that the only difference between BASIC and COMPILE is
case sensitivity. I will trust your observation however and suggest
that anyone who cares should file this with RD as an action item.
About Options, I think Flash-compiling is a requirement for these
functions.

Hmmm - yes, the included code is all in caps. If your code is in
lower case and you use BASIC then those vars will be unassigned. When
you use Compile, your o$whatever is the same variable as their
O$WHATEVER and everything will work. In fact, if you look at the code
that Dave posted, O$RDWR is in caps. I'll bet a donut that's there
because the author liked to use the Basic verb and they did some head
scratching when o$rdwr didn't work with the rest of their lower case
code. :^D

On the other side. Since Compile has been with us for over 10 years
now, why would anyone on D3 still be using the Basic verb to compile?
Flame jacket on
helmet on
rosey glasses on
just took another Dilligaff pill
(Do I look like I give a flying f_____?)
I know I know, it's the same reason some people (and you know who you
are ) still use the ap command from *nix.

BTW, Jesse - don't hardcode the values for o$rdwr or o$append.
They're already in that include item that Peter has pointed you to.

Good luck.
T

Hi Tony
The original includes were in an NT file that was removed later.
I agree that having common code is a good idea however one has to tell
people about it. Also calling it unix is the height of stupidity.
If you check the documentation you will find that it constantly refers to
unix and one can only guess that it also means NT. In fact you will find
several buried references that say does not work on Windows.
As for not working with BASIC, that is at least because the includes have
some lower case in them. Personally when I find one booboo like that I
assume that there are probably others.
Overall it is the best idea with the worst documentation in the whole D3
product.
Peter McMurray
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

"Excalibur" wrote:

Hmm, well I suppose this is beating a dead horse, but I was using
those functions in Unix before NT existed and the functions were in
the bp,unix.h file. You have to remember that AP came from Unix, it's
not like they developed an nt.h file and then moved things into the
unix.h file as an after thought.

Having worked with NT from its inception my increasingly poor memory
doesn't include a note of ever having to deal with functionality being
moved from unix.h to something like nt.h and then having to move back.
I have clients running my code that have shifted platforms and this
has never come up. This is not the sort of malicious game that PS/RD
has ever played. There are no comments in fnctrl.h or anywhere else
that mention anything but bp,unix.h and bp,includes

Whatever the historical case, it's all in unix.h now and I doubt it
will ever move.


For better or worse the documentation for this stuff, including
references to unix.h, has been virtually unchanged since the first
edition of EPick. All editions of AP Ref and D3 Ref have had the same
text. Yes, the docs pretty much suck on these %functions (sorry Jon),
but then again, hardly anyone uses them and very few people other than
myself have taken the time to request doc changes in this area for the
last 15 years - once again Supply is commensurate with Demand.


Ha! Wait til they put an FSI in Unix and then tell us we need to use
nt_commands. Get over it, there are too many things in this IT market
that are done the way they are purely for historical reasons.
Changing them might please a new generation who likes things nice n
tidy, but it would outrage a mass of legacy developers - present
company included.

For the most part, the %functions are just pass-thru functions to
their POSIX counterparts, which I believe is what the Windows
functions are based on as well. When I need help with the D3
%functions I pull out Unix C docs, rarely MS C++.

I don't see asthetic sensibilities (Unix goes in a unix file and NT
goes in an NT file) as sufficient justification to piss off even a
small group of %function developers. Anyone who reads the doc will
see where stuff is and just ignore the reference to unix.

Hell, maybe Pick Systems was too shortsighted when they named the file
unix.h in the first place, and they should have called it 'foobar.h'
to keep options open for completely different environments. Again,
it's all historical and citing stupidity 10 years after something has
been in place is just another flavor of the same.

If you don't like calling it unix.h, create your own q-pointer called
nt.h that points to unix.h and this whole problem is solved in about
20 bytes.


Those references to Windows were only added within the last couple
years - we're lucky to get that, though you'll note in the new D3 Ref
that there are a great many places where differences between Unix and
Windows are clearly defined - at least more so than before. If you
want better documentation you should inform your vendor. Unless
someone actually acknowledges reading the docs it's tough for them to
justify making changes.


That's a good point. I didn't catch this before so my previous
comment about "if you use Basic" isn't even valid - you must use
Compile or your code simply won't compile.


Booboo? Every example in EPick through the current D3 Ref uses lower
case for %functions, which implies it must be compiled with the
Compile command. It's only a booboo if you expect o$append to really
be different from O$APPEND, or 'ID' to be different from 'id'. This
is yet another of those "why is this all of a sudden a booboo when it
hasn't changed in 15 years!?"

In fcntl.h there is a line which I would consider to be a bug. If
it's important to anyone here, feel free to report it:
The statement "casing off" is intended to ensure that AIX=aix,
LINUX=linux, etc. But they leave casing off which could be an issue
for apps that are expecting upper and lower case characters to mean
different things, as might very well be the case in a sophisticated
app using sockets, encryption, passwords, etc. The fix for this is
that they should check system(28) to see what the casing setting is,
and make sure they reset that value on the way out. Or they should
use checks like:
if oconv(data,'mcu') = 'VALUE' then...
This way they won't need to monkey with the casing setting at all.
The obvious fix for us in the field is to simply be sure to set the
casing After the Include, which is probably what all apps have done
to-date anyway.


We agree on yet another point. That's consistent for most
products though. The more sophisticated features are the least used
and have fewer people picking on them. As sophistication increases,
so decreases the ability for people to properly QA related docs and
code, and we tend to see more doc inaccuracies and more functionality
issues related to the more complex features. The more sophisticated
developers don't care much about anomalous documentation, if they read
docs at all, and they usually won't take the time to report errors for
people who are likely to need it the most. This explains well why
some people are still discovering great features that have been in
these products for years - and why people are just now discovering
related bugs and doc issues.

T

<big snip>
Hi Tony
I am fascinated by your response. I have the Advanced Pick Reference Manual
on my desk - being spiral bound it is handy - no mention of these things
that I can find. Where you got the idea that this all came in with Unix I
do not know. I have been transferring data between disparate operating
systems since the 1970's. In fact the best program I have ever seen was the
R83 DOS to Pick and back offering. I reported to Pick that it was broken -
I believe it was DOS 6. The Bone idle careless reply was that it could not
be fixed. I edited it and found a thing of beauty. Copiously documented,
I made the simple changes , a couple of bytes as I recall to the DOS file
header definition. It worked a charm. Then after an upgrade it was broken.
I looked and found that PS had let some junior wannabee loose. They had
thrown away all the beautiful documented code and come up with a "brilliant"
way to stuff things up. The programmer dimmed the receive record as
RECORD(1) then read in the next record and redimmed the array ad nauseam.
Of course it was a disaster as we used it every day on numerous sites.
Luckily I retrieved the old code that I had fixed and all was well again.

There definitely was a DM,bp,nt file on the first NT releases.

Documentation. Ignoring the mess that was the Update version of the REF
file - how many people knew that it contained interesting articles until
Grigory freed it up! I have only ever met one person who lifted a Jaguar
bonnet to check a Holden engine, and he also mowed the mat at the office
door - well BP green is so confusing when the grass surrounds the office.
If you label something Unix most normal people think that you mean it. I
refer you to the new better and brighter docs - definitely an improvement.

"C functions can be called from a FlashBasic program or subroutine in D3
UNIX implementations using a syntax similar to that of normal C"
NOTE - See the Unix man pages for information on any C funtions that are not
represented in this guide"

"The %creat()fuction creates a new UNIX file or prepares to rewrite an
existing UNIX file designated by str for write only"

These statements are hardly likely to enthuse an NT user. However if , like
me, one is determined, several pages further on one comes to
"For Windows: Not Supported"
AH Hah! Here we have a way of twisting it, if it does not say no it must
mean yes. Yhis guy must have a great way with the ladies in these PC days.
Then just as the Unix guys are getting all puffed up the fox jumps into the
henhouse.
"NOTE - Sockets are a Berkeley Software Distribution (BSD) extension, which
may not be available on all Unix platforms"
buried on page 498.

You wonder why more people do not know how to use these functions!
Peter McMurray

"Excalibur" wrote:

Those spiral versions were crap. The documentation people essentially
eliminated anything they didn't understand or didn't have time to
check - including all of the See Also references and Warnings. Mind
you, when Jon and his people wrote EPick in the first place, they put
a lot of delicious information into the Warnings sections - some of
that info wasn't just a warning but critical information toward
understanding how some features work. All of that was removed in
those spiral editions. The prior edition, AP Ref v2 (=4th edition)
from 1995 is a better reference.

After the company sacked the entire documentation department, the next
generation of doc people put all of the goodies back into the D3 Ref
Manual. While that was still mostly crap and just an update of AP
Ref, it did have a lot of new material that was accumulated in the
online version of the docs. (At PS/RD this data is in an account
called KRB, for King Richard's Bible, a generous reference to Dick.)
It wasn't entirely accurate, but that's what happens when you hire
"writers" to write technical documentation instead of technical
people. IMO the proper way to do that was to get tech people to write
about what they knew and get the writers to ensure the material was
clear, complete, and had nice spelling and punctuation. While the
spelling was immaculate in D3 Ref the content was still grossly
lacking. Most of that has been fixed in the latest version of the D3
Ref, though in their rush to get that cut out for D3 v7.5 there are
still some major inaccuracies which will probably only be fixed when
people in the field point them out.


Well, R83 didn't have an underlying OS file system or sockets. That
was introduced with AP over Unix. Those functions are POSIX
compliant: "Portable Operating System Interface for uniX". Note also
that those functions were created way before Windows 95, let alone NT.
For AP/DOS over Win95 we didn't use %functions, we used import/export
(as I recall). So again, these functions were exclusively used with
Unix until AP became D3 in version 6.0, which was later ported to
Windows.

So ends our history lesson for the day. I apologize for a fading
memory if I got some of this wrong.

[snip irrelevant anecdote]

OK


Anyone who actually read it? Grigory didn't do anything except
publish copywritten material without permission from the owners. The
material was already in there.

Did you just slip into Dan Fisher emulation mode?

HA! Fooled you! Have you ever used Linux? I thought Yum was
something a Python said after he ate a Pup or a Cat - now all of these
words have completely different meanings.


Hmmm, as I recall for the last year I've been the guy encouraging
people to use the new docs. Might I suggest you trash your spiral
bound doc, take your own advice and look for references to unix.h?


Ref my note about the diffence between writers and technicians who
actually use and understand the software.

Bottom line as always is, if you don't like it, tell your vendor.
Venting in a public forum isn't going to change the product.


I don't wonder at all. For many years before you came back to this
scene, with the same passion that you've shown I was trying to
encourage people to 1) read the manuals, 2) use the features that
exist, and 3) petition PS/RD to fix inaccuracies in product and docs.

I even proposed here and officially to RD that we create an open doc
repository where people could correct the docs, and RD could
incorporate the changes into the official text. People here said
collaborative documentation wouldn't work - oh that was before "wiki"
became a household word - and RD felt they could do a much better job
of maintaining their documentation - that was before they terminated
everyone except one guy now in their documentation department.

And people wonder why I don't give a crap about some of these things
anymore. The flag is yours to wave. Good luck.

I'm burned out on this, I hope you are too.
T

"Tony Gravagno" wrote
Bad reference material, but short & simple
enough to make really good 'intro' books for
non-pick-aware new staff -- biggest "gotcha's" were
a) they often didn't explain the full pathing used,
like in 'this is file dm,messages,'
b) nor reinforce that that word before many of their
listings was the Item ID of said listing.