DOS 3.5, TOUCH.BAS

[Rolf Seebach]

Hi guys, it has been a while for me with DOS 3.5.

I want to utilize the TOUCH program that is available in EXAMPLES.
However, it does not compile.
The program requires $INCLUDE PB35.INC, which is available.
PB35.INC requires DOSUNIT.BAS which it cannot find although it resides in the same directory.
So I add $INCLUDE DOSUNIT.BAS ==> apparently OK.
But now it complains that

FUNCTION AddFileHandles( ) PUBLIC

is multiple defined.

Looking through all three files I cannot find any duplicates.

But DOSUNIT says something about having file handles limited to 15.
My CONFIG.SYS specifies 64 files with 32 buffers. That should be enough?
TOUCH is supposed to set the date for 40 files, way below the 50 limit.
What is wrong here? Thanks, Rolf



------------------

[Tom Hanlin]

You should not $INCLUDE DOSUNIT.BAS -- DOSUNIT is part of the PB35.PBL
library that PBTOUCH uses. That's why you see the duplicate definition.

DOSUNIT was designed for compatibility across a wide range of DOS
versions. So, it doesn't support more than 15 file handles. However,
that's the limit on the number of files that a single program can
have open all at the same time. This will not be a problem for PBTOUCH,
which only opens one file at a time.


------------------
Tom Hanlin
PowerBASIC Staff

[Rolf Seebach]

Thanks, Tom, for trying to help.
I did what you recommended but -- alas -- I am where I was before.
PBTOUCH.BAS compiles, but does not execute.
It complains that it "Can't find DOSUNIT.BAS New name (including path)"

My setup is as follows:

F:\PB\EXAMPLE\PBTOUCH.BAS
F:\PB\EXAMPLE\PB35.INC
F:\PB\EXAMPLE\DOSUNIT.BAS

all in the same directory.

What am I missing here? Do I need another entry in Directories
or in Config.SYS? The compiler, of course, is in F:\PB
Maybe I should move all three files out of \EXAMPLE\ and into PB\ ?
Thanks, Rolf

------------------

[Karl Lessmann]

.

[This message has been edited by Karl Lessmann (edited September 23, 2003).]

[Rolf Seebach]

Hi Karl,
I took my own advice and moved all files to F:\PB\ where the compiler is.

Still no luck!

Then I found out that there are more files involved: PB35.PBL and DOSUNIT.PBU.
I moved those two also to F:\PB

Also made sure that the compiler directories all point to F:\PB as well
(except for the "Executable Directory:" which is left blank.

Fired up PBTOUCH again FAILURE!
Error 75 (wrong path/file) on line 589 in DOSUNIT.
But it does not say which path/file and the pointer rests on an empty line.

Tom Hanlin: "DOSUNIT was designed for compatibility across a wide range of DOS
versions."

I understand that. I also understand that all the files have to be accessible.
HOWEVER: The devil lies in the details. When there are so many files interrelated and
they are so much spread around and there are so many options to be considered .....
would it not be prudent to publish a roadmap for such a complicated undertaking
and to map out all the steps to be done? As I wrote a few months ago: The biggest
selling point of any compiler is its user friendliness to gain [B]productivity[\B].

Here I am spending four hours on something so little that should be done in ten minutes
and it still does not work. That is not productive. Ah, but how would I learn if I did
not go through this little hell? Irrelevant. I probably will not need to this again for
the next five years and by then .... who knows?
What do I do now? Thanks, Rolf


------------------

[Karl Lessmann]

.

[This message has been edited by Karl Lessmann (edited September 23, 2003).]

[Rolf Seebach]

Hi Karl, yes, PBTOUCH.BAS
It compiles here too, but it does not execute.
The BAS program says to $INCLUDE DOSUNIT.BAS. But that program
has also been compiled to a PBU unit. Maybe it should say $INCLUDE DOSUNIT.PBU?
I am really at a loss here.
Rolf

------------------

[Rolf Seebach]

Hi guys,
It finally works --- half way.
The problem lies in an unsuspected corner: Sub-Directories.

The COMMAND line says A:\*.* 08-31-2003 05:00:00
and in .BAS: File$ = DIR$(Spec$,23) [1+2+4+16=23]
with the first two entries on the floppy being two SUBs.
That is what gives ERROR 75. Why?

If I set the DIR$ attribute to six or seven, the program works
but it does not change time/date for the SUBs or the files in them.
It simply ignores the SUBs, as can be expected.

OK, so just change the COMMAND line to A:\SUB1\*.* date time
That should work? No, it does not. Neither the SUB1 nor the files
in it are affected.

The question now becomes: What is the correct COMMAND line(s) and DIR$(,)
to affect the date/time in >all< the SUBs and files on the floppy?
Can anyone help, please? Thanks, Rolf


------------------

[Karl Lessmann]

.

[This message has been edited by Karl Lessmann (edited September 23, 2003).]

[Lance Edmonds]

Rolf, it looks like you actually resolved the $LINK problem when you started getting "can't find DOSUNIT.BAS" errors at run-time... since that error would mean that a run-time error occurred in the code that was used to compile DOSUNIT.PBU, but PowerBASIC was not able to open the DOSUNIT.BAS file to show you where the error was occurring in the PBU.

Next, a file attribute of 23 indicates that the file is read-only, so you probably should NOT try to change it's time/date stamp.

However, the real issue is that the "." and ".." names are really "pseudo" directory names, as opposed to being "actual" directory names.

While DOS generally displays such names when obtaining a "DIR" listing of a subdirectory from the command-line prompt, many OS's simply don't return the "." and ".." names to DIR$ because they are "pesudo" names.

Therefore, I'd suggest you modify your code to ignore "." and ".." as your DOS (OS/2 DOS) does seem to return them.

Alternatively, use ON ERROR RESUME NEXT and simply trap or ignore the errors and move on.

PS: Don't forget that if you modify DOSUNIT.BAS then you will need to recompile it to DOSUNIT.PBU. If your code is using $LINK "DOSUNIT.PBU" then you can recompile your main code at that point, but if your main code is using $LINK "PB35.PBL", then you will need to update the .PBL with the recompiled .PBU using the PBLIB utility before recompiling the main code.

PPS: Personally, I'd far prefer to Block-Copy the required code from DOSUNIT.BAS and paste it into PBTOUCH.BAS as required... thus avoiding the whole issue of .PBU (units) and .PBL (library) files... at least until the DOSUNIT.PBU code is working to your tastes.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Rolf Seebach]

Hi Lance, you got me there.
What is "." and ".." ? Do you mean *.* ?

My OS in this case is Win98SE.
If I copy DOSUNIT.BAS into the PBTOUCH.BAS, as I also had considered,
would I not inherit the same sub-directory problem as well?

My floppy looks as follows:

[CODE]
A:\SUBDIR1
\file1
\file2
\SUBDIR2
\file3
\file4
\file5
\file6
\file7
etc.
[\CODE]

More than half of the files are READ-ONLY, but I could make
them so >after< the Date/Time stamp.

For a nice professional, consistent look I would like that
all the directories and files have the same date and time stamp.

What do you suggest? thanks, Rolf



------------------

[Rolf Seebach]

Hi Lance,
guess I forgot how to set the CODE. How do you turn ON HTML?

Files 5,6 and 7 are supposed to be under A:\ (the root)
Sorry, Rolf


------------------

[Rolf Seebach]

Hi Lance, to my horror I just realize that the files in SUBDIRs one and two
have long file names. So the whole thing would not play anyhow.

So I looked for something in PBCC3.5.
There I find SetFileDate(filename, date, time)

Questions: It is coded for only one file. Can I do the *.* to use ion a .BAT file environment?
This code also asks for GetFileDate( ) is that still required?
It has parameters such as CreationTime. Does that include the date?
When I "set" the date/time ... does that include all three time stamps?

It really would be nice if these functions had a few sentences in them that explained any
limitations and restrictions. Would save a lot of frustrating hours.
Thanks, Rolf


------------------

[Rolf Seebach]

Hi Lance, created a ccTouch.BAS file in CC3.5 with Win2K-SP4.

It works there in that I now can process long file names. But the rest still has the same limitations.
DIR$() brings out the file names under SUBDIRs, but not the SUB name itself in conjunction with the file name.
Therefore, if the path\name is A:\SUB1\File.01 then DIR$ will give me first SUB1 and then File.01, but not both together.
That does not help.
To circumvent this limitation I now parse the path separately from the file names and then stitch them back together.
This requires separate calls to ccTOUCH.

However, I have not found a method that changes a directory's time stamp itself.
In the above example Windows Explorer will show
A:
SUB1

where SUB1 has its own time stamp on the right side of the screen.
How can I change that time stamp for the SUB1? It looks funny if all the files have one time, but the folders for it have not.
How is that done? Thanks, Rolf



------------------

[Tom Hanlin]

I'm not sure whether it's possible. I'll see what I can find out.

------------------
Tom Hanlin
PowerBASIC Staff

[Tom Hanlin]

The standard DOS and Windows functions for setting file time/date stamps
don't appear to work on directories. It might be worth trying the old DOS 1.x
FCB-style file functions, just in case. You'd need to use CALL INTERRUPT or
asm code from PB/DOS.


------------------
Tom Hanlin
PowerBASIC Staff

[RM Green]

Originally posted by Tom Hanlin:
The standard DOS and Windows functions for setting file time/date stamps
don't appear to work on directories. It might be worth trying the old DOS 1.x
FCB-style file functions, just in case. You'd need to use CALL INTERRUPT or
asm code from PB/DOS.

Tom,

The Extended Get/Set File Attributes function (int 21h, ax =
7143h) will work for changing the date/time on directories,
so Rolf's project is doable with PB3.5. This function is
part of the DOS 7.X LFN API and requires Ifsmgr, so it only
works in a Windows DVM not pure DOS.

Just tested this (on a Win98 box) and it handles regular
directories just fine, but while it seemed to succeed on the
directory aliases (. and ..) while the program was running,
doing a DIR outside the program revealed that the date/time
for those had not actually changed.

Anyway, I now have a little program that can reset directory as
well as file date/time stamps (created, modified, and last
accessed [date only for that one]) and is LFN compatible
(uses an LFN compat clone of DIR$). Rolf, if you want to take a
look at this just say so and I'll spruce it up and make it
available for download.

Bob


------------------