Windows XP startup question

and

this

assumes

specific

these

with

So, convert the machine to Linux. Run the automation app in wine if = necessary.

Nicked from Novell then twisted beyond recognition. Followed up with an=20 insanely cack-headed implementation. The Novell bindery was actually ok.

didn't

startup

in

via

any

just

to

on

written

start

maybe a

Domain error. The directory and concepts related to "/etc/rc.d" do not=20 exist in WinXP.

Larkin

is

up.

development in

from

systems.

(whatever

I suspect that if you took all of the relevant SysAdmin courses that you=20 would have the tools to do task. It will cost you high 4 figures though.

is

I suspect that like the shrinks and the light bulb, he don't wanna = change.

that

and

this

assumes

specific

these

just

be

on

with

This is the First time i have ever heard of MSWin file semantics being=20 called crisper than those of *nix. Maybe way up in KDE land they are=20 not so good, but directly to the *nix OS they are really great.

Trivial in *nix.

that

didn't

startup and

in this

assumes

specific

via these

any

just

to be

on

written with

Linux,

=20

Dining Philosophers.

When did Microsoft ever invent anything? Well, Bob maybe.

John

I've got that working, by putting a shortcut in

C:\Documents and Settings\All Users\Start Menu\Programs\Startup

as Greegor suggested. But it applies to all users, so I can't have a Guest account. I have to have only the admin account, and it must startup automatically after a power fail/restart.

The ideal situation would be to have my program run at powerup, before anybody logs in.

John

But I use all sorts of engineering apps, commercial and home-brewed, on it. And I'm programming the app in PowerBasic, and I don't know if that works under Wine.

The machine is absolutely identical to the one in my office, with front-panel hot-plug Raid drives. The entire os+apps install consisted of popping a drive out of my work machine and plugging into the new one... one minute instead of a week or so.

John

Each operating system implements things differently.

The cost of training a man from the street is not much different from one operating system to an other.

Look at SrvAny in the Resorce Kit

Unix file system semantics are really loosey-goosey. You can call fopen() on a file that somebody else already has open for write, and the call will succeed. Windows and OS/2 will make that call fail, so that file handles are good synchronization mechanisms--not true in Unix.

In Unix, a file is deleted when there are no inodes pointing to it and no open handles to it, but it isn't guaranteed to happen in a timely manner. It's quite possible for a fopen() to succeed while the file is waiting to be deleted, so that it disappears while a process has a handle to it. That one gave me *fits* in porting my clusterized EM simulator to Linux.

So yeah, Windows file system semantics are way crisper than Linux's.

Cheers

Phil Hobbs

Are you really sure about this? What kind of Unix? I'm using file based databases used by several processes in parallel on Linux a lot and database locking is performed through the filesystem. This never gives any problems. Besides, you should use mutexes/semaphores as a process synchronisation mechanism not file handles!

Well, they have brought that stupidity into the Unix world , in the form of the nvi editor. If you have, say, a script file open in nvi, you can't execute it, instead you just get a "text file busy" error. This is the kind of annoying thing that at least used to happen in Windows a lot, couldn't start watching a video file before it was completely downloaded for example.

Yup, huge timing hole. Much much worse on NFS, which is where it initially showed up. Files that were being written to would randomly disappear. Windows and OS/2 NETBEUI shares worked great.

Right, because on Linux it's broken!

I needed a locking mechanism that worked regardless of whether the interacting processes were on the same machine or not, because the postprocessor design was to have each process write to a common set of files--the file format was designed so it didn't matter what order that happened in, as long as the file system prevented two files from having a write handle to the same file at the same time. Only in Linux it didn't....and of course mutexes only work on a single box, which is why file handles were the right mechanism for a clusterized simulator. I wound up with an ugly hybrid kluge--mutexes plus file handles--which did work regardless of where the writing processes were running.

Cheers

Phil Hobbs

So you'd like to execute a file when another process has it open for

Windows and OS/2 allow multiple read handles, and you can explicitly ask for shared files--sopen() exists there too--but you have to ask for it. That's a good idea IMO--no extra work when you need it, and fewer bullets through the shoe leather.

Cheers

Phil Hobbs

A slight correction. The unlink() problem happened when my simulator deleted an old file, created a file with the same name, wrote to it, and closed it so that the other processes could write to it. Sometimes the file got deleted during a run rather than at the beginning. On NFS this delay could be *tens of seconds*, even with all the cluster boxes in the same rack.

Cheers

Phil Hobbs

In message , JosephKK writes

It worked well for Novell. MS took a few things from them.