Hi All!
Is there an API for IEEE 1394 included with Windows 2000 Professional?
If so, where is it documented?
If not, is there any open source software
to be found supporting general purpose use of 1394 as an I/O buse?
David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)
> Is there an API for IEEE 1394 included with Windows 2000 Professional?
Yes, but for kernel-mode code only - not exported to the user mode.
If so, where is it documented?
In the WDM DDK.
Max
Thanks.
So how does a user app do i/o from/to the 1394 bus?
(I’ve now got a 1394 card installed in my system)
At 01:22 PM 03/29/2000 +0400, you wrote:
> Is there an API for IEEE 1394 included with Windows 2000 Professional?
Yes, but for kernel-mode code only - not exported to the user mode.
> If so, where is it documented?
In the WDM DDK.
Max
You are currently subscribed to ntdev as: xxxxx@mindspring.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)
Unless the card manufacturer provided a w2k driver or you can find some
generic 1394 driver/api package, you are going to have to write a device
driver for the device.
-----Original Message-----
From: David Feustel [mailto:xxxxx@mindspring.com]
Sent: Wednesday, March 29, 2000 7:47 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Windows 2000 API for IEEE 1394Thanks.
So how does a user app do i/o from/to the 1394 bus?
(I’ve now got a 1394 card installed in my system)At 01:22 PM 03/29/2000 +0400, you wrote:
>> Is there an API for IEEE 1394 included with Windows 2000
Professional?
>
>Yes, but for kernel-mode code only - not exported to the user mode.
>
>> If so, where is it documented?
>
>In the WDM DDK.
>
> Max
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@mindspring.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)xxxxx@mindspring.com
http://www.mindspring.com/~dfeustel
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
At 08:24 AM 03/29/2000 -0500, you wrote:
Unless the card manufacturer provided a w2k driver or you can find some
generic 1394 driver/api package, you are going to have to write a device
driver for the device.
David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)
> So how does a user app do i/o from/to the 1394 bus?
(I’ve now got a 1394 card installed in my system)
You will need to write a kmode driver talking to the MS 1394 stack - and
your
app will talk to this kmode driver. This is the only way.
Max
I’d start looking into the following:
“Ulead Systems has been the first company to ship video editing software for
the IEEE 1394 Open Host Controller Interface OHCI-Lynx chip from Texas
Instruments Inc. For the past several months, Ulead worked closely with
Texas Instruments and Microsoft to ensure its award-winning Ulead
VideoStudio 3.0 DV software delivers the most comprehensive support for IEEE
1394 DV than any other program in the sub-$100 consumer video editing
category.” -www.ulead.com
This may be generic enough that you can communicate with the device via a
microsoft defined api. However if ulead has not seen fit to document the api
you are going to have to grovel through the web and whatever documentation
microsoft and TI care to provide.
-----Original Message-----
From: David Feustel [mailto:xxxxx@mindspring.com]
Sent: Wednesday, March 29, 2000 10:45 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Windows 2000 API for IEEE 1394At 08:24 AM 03/29/2000 -0500, you wrote:
>Unless the card manufacturer provided a w2k driver or you
can find some
>generic 1394 driver/api package, you are going to have to
write a device
>driver for the device.A Ulead Video Editing Software Package is included with the driver,
but no documentation on the 1394 User API that the Ulead software
is using.David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)xxxxx@mindspring.com
http://www.mindspring.com/~dfeustel
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
I registered the software at the Ulead website and looked for
DFW-500 (1394) adapter info. It looks like the website doesn’t
have complete info for this (new) adapter yet. I’ve also emailed
D-Link tech support for driver/api info.
At 11:48 AM 03/29/2000 -0500, you wrote:
I’d start looking into the following:
“Ulead Systems has been the first company to ship video editing software for
the IEEE 1394 Open Host Controller Interface OHCI-Lynx chip from Texas
Instruments Inc. For the past several months, Ulead worked closely with
Texas Instruments and Microsoft to ensure its award-winning Ulead
VideoStudio 3.0 DV software delivers the most comprehensive support for IEEE
1394 DV than any other program in the sub-$100 consumer video editing
category.” -www.ulead.comThis may be generic enough that you can communicate with the device via a
microsoft defined api. However if ulead has not seen fit to document the api
you are going to have to grovel through the web and whatever documentation
microsoft and TI care to provide.
David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)
At 05:20 PM 3/29/00 +0400, you wrote:
> So how does a user app do i/o from/to the 1394 bus?
> (I’ve now got a 1394 card installed in my system)You will need to write a kmode driver talking to the MS 1394 stack - and
your
app will talk to this kmode driver. This is the only way.
Does this strike anybody else as pretty broken? Isn’t the whole idea of
device drivers to make the interface to a unique device have a common
interface to an application. The simple interface to both 1394 and USB
devices seems like an app should be able to just open a correctly named
stream, and do reads and writes. For that matter, the concept of block
devices and stream devices seems like it fits most devices. Block devices
can seek, and there is a set/get “attribute” commands to control options.
My concern is the number of unique API’s is growing at a much faster rate
than us programmers can learn them. One of the purposes of object oriented
design is to limit this API explosion. A “read” verb should work on a wide
variety of object types, with the details of it being a network card,
microphone attached via USB, video capture device, network connection
across the world, or local disk file system all being pretty much transparent.
Many years ago, I realized IBM’s goal was to suck everybody on earth into
their proprietary “knowledge” sphere. It was ok to increase complexity, as
this brought more people into the IBM universe. It seems like Microsoft is
doing exactly the same thing. Pretty soon (or maybe already), there will be
no such thing as a “Windows software developer”, there will be a “1394
kernel API specialist”. To get any real project done will take a sea of
specialists to do their little thing. Personally, I’d much rather be the
god of my systems, where I have control over and can do
everything/anything, instead of a worker ant with no hope of understanding
the “big” picture.
A little while ago, I had to stop and think, am I still an “expert” in
Windows. It seemed like my answer was a lot less clear than I would have
liked. In the last 3 years I have learned “x” amount about Linux. In those
three years Linux has become maybe 30% more complex. In those same 3 years,
Windows (now W2K) has become probably 200%+ more complex. If we assume the
acquisition of knowledge about each OS continues at a constant rate, it’s
clear that at some point I will know a huge percentage more about Linux
than the percentage I know about Windows. So essentially, Microsoft is
making me a Linux “expert” by their out of control API expansion. I agree
than rich functionality is a nice feature in an OS, bit only if that
functionality doesn’t take an army of people to figure out how to use.
Just my $0.02.
The person you were responding to may have been jumping to conclusions.
While I never miss an opportunity to bash Microsoft, and their PnP
architecture needs a whole lot of bashing, (but what’s the competition?)
I think that there is a very good possibility that this device in fact fits
into one of the defined WDM/PnP device interface architectures and may
indeed have an open documented api. Its just a matter of figuring out what
the thing is and what the interface is and what its damn GUID is.
-----Original Message-----
From: Jan Bottorff [mailto:xxxxx@pmatrix.com]
Sent: Wednesday, March 29, 2000 4:03 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Windows 2000 API for IEEE 1394At 05:20 PM 3/29/00 +0400, you wrote:
>> So how does a user app do i/o from/to the 1394 bus?
>> (I’ve now got a 1394 card installed in my system)
>
>You will need to write a kmode driver talking to the MS 1394
stack - and
>your
>app will talk to this kmode driver. This is the only way.Does this strike anybody else as pretty broken? Isn’t the
whole idea of
device drivers to make the interface to a unique device have a common
interface to an application. The simple interface to both 1394 and USB
devices seems like an app should be able to just open a
correctly named
stream, and do reads and writes. For that matter, the concept of block
devices and stream devices seems like it fits most devices.
Block devices
can seek, and there is a set/get “attribute” commands to
control options.My concern is the number of unique API’s is growing at a much
faster rate
than us programmers can learn them. One of the purposes of
object oriented
design is to limit this API explosion. A “read” verb should
work on a wide
variety of object types, with the details of it being a network card,
microphone attached via USB, video capture device, network connection
across the world, or local disk file system all being pretty
much transparent.Many years ago, I realized IBM’s goal was to suck everybody
on earth into
their proprietary “knowledge” sphere. It was ok to increase
complexity, as
this brought more people into the IBM universe. It seems like
Microsoft is
doing exactly the same thing. Pretty soon (or maybe already),
there will be
no such thing as a “Windows software developer”, there will be a “1394
kernel API specialist”. To get any real project done will
take a sea of
specialists to do their little thing. Personally, I’d much
rather be the
god of my systems, where I have control over and can do
everything/anything, instead of a worker ant with no hope of
understanding
the “big” picture.A little while ago, I had to stop and think, am I still an “expert” in
Windows. It seemed like my answer was a lot less clear than I
would have
liked. In the last 3 years I have learned “x” amount about
Linux. In those
three years Linux has become maybe 30% more complex. In those
same 3 years,
Windows (now W2K) has become probably 200%+ more complex. If
we assume the
acquisition of knowledge about each OS continues at a
constant rate, it’s
clear that at some point I will know a huge percentage more
about Linux
than the percentage I know about Windows. So essentially, Microsoft is
making me a Linux “expert” by their out of control API
expansion. I agree
than rich functionality is a nice feature in an OS, bit only if that
functionality doesn’t take an army of people to figure out how to use.Just my $0.02.
- Jan
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
At 04:21 PM 03/29/2000 -0500, you wrote:
The person you were responding to may have been jumping to conclusions.
While I never miss an opportunity to bash Microsoft, and their PnP
architecture needs a whole lot of bashing, (but what’s the competition?)
I think that there is a very good possibility that this device in fact fits
into one of the defined WDM/PnP device interface architectures and may
indeed have an open documented api. Its just a matter of figuring out what
the thing is and what the interface is and what its damn GUID is.
David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)
WinZip will extract cab files. Also, doesn’t w2k explorer allow browsing of
cab files?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of David Feustel
Sent: Wednesday, March 29, 2000 2:03 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Windows 2000 API for IEEE 1394At 04:21 PM 03/29/2000 -0500, you wrote:
>The person you were responding to may have been jumping to conclusions.
>While I never miss an opportunity to bash Microsoft, and their PnP
>architecture needs a whole lot of bashing, (but what’s the competition?)
>I think that there is a very good possibility that this device
in fact fits
>into one of the defined WDM/PnP device interface architectures and may
>indeed have an open documented api. Its just a matter of
figuring out what
>the thing is and what the interface is and what its damn GUID is.
>I found a 1394_ddk.cab file in the w2kddk. There is api code there
but unfortunately I don’t know how to properly unpack cab files
yet, so the files I have are numbered from 0 to 50 (i.e. they
don’t have the
correct filenames).David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)xxxxx@mindspring.com
http://www.mindspring.com/~dfeustel
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
“Extract.exe” comes with operating system. It does the work of listing and
extracting contents of CAB files.
Inaki.
-----Original Message-----
From: Jamey Kirby
Sent: jueves 30 de marzo de 2000 1:09
To: NT Developers Interest List
Subject: [ntdev] Re: Windows 2000 API for IEEE 1394WinZip will extract cab files. Also, doesn’t w2k explorer allow browsing
of
cab files?> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of David Feustel
> Sent: Wednesday, March 29, 2000 2:03 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Windows 2000 API for IEEE 1394
>
>
> At 04:21 PM 03/29/2000 -0500, you wrote:
> >The person you were responding to may have been jumping to conclusions.
> >While I never miss an opportunity to bash Microsoft, and their PnP
> >architecture needs a whole lot of bashing, (but what’s the
competition?)
> >I think that there is a very good possibility that this device
> in fact fits
> >into one of the defined WDM/PnP device interface architectures and may
> >indeed have an open documented api. Its just a matter of
> figuring out what
> >the thing is and what the interface is and what its damn GUID is.
> >
>
> I found a 1394_ddk.cab file in the w2kddk. There is api code there
> but unfortunately I don’t know how to properly unpack cab files
> yet, so the files I have are numbered from 0 to 50 (i.e. they
> don’t have the
> correct filenames).
> —
> David Feustel
> Fort Wayne, Indiana
> 219-483-1857 (voice)
>
> xxxxx@mindspring.com
> http://www.mindspring.com/~dfeustel
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
You are currently subscribed to ntdev as: xxxxx@pandasoftware.es
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Hi,
I don’t know how much whether I am right or not, or am throwing
wrong piece of advice. There is one 1394API.dll and it’s documentation in
the Win 2000 DDK. Won’t this document help u?
Regards,
Chaitanya
Where is the 1394.dll and its associated documentation to be found?
At 10:06 AM 03/30/2000 +0530, “Bhaava Chaitanya Kancherla”
wrote:
>Hi,
> I don’t know how much whether I am right or not, or am throwing
>wrong piece of advice. There is one 1394API.dll and it’s documentation in
>the Win 2000 DDK. Won’t this document help u?
>
>
>Regards,
>Chaitanya
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@mindspring.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
—
David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)
xxxxx@mindspring.com
http://www.mindspring.com/~dfeustel
At 10:59 AM 03/30/2000 +0200, you wrote:
“Extract.exe” comes with operating system. It does the work of listing and
extracting contents of CAB files.Inaki.
When I run extract I get as output a list of 51 files with names
1394_DDK_FILE_1
…
1394_DDK_FILE_50
I can’t find the files themselves.
David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)
Hi David,
I have the Win 2K DDK(RC1) which has the above documentation. I have
not yet loaded the full DDK on my machine. I assumed that it is present in
that one too.
Is it not there.
Regards,
Chaitanya
----- Original Message -----
From: David Feustel
To: NT Developers Interest List
Sent: Thursday, March 30, 2000 9:19 PM
Subject: [ntdev] Re: Windows 2000 API for IEEE 1394
> Where is the 1394.dll and its associated documentation to be found?
>
> At 10:06 AM 03/30/2000 +0530, “Bhaava Chaitanya Kancherla”
> wrote:
>
> >Hi,
> > I don’t know how much whether I am right or not, or am throwing
> >wrong piece of advice. There is one 1394API.dll and it’s documentation in
> >the Win 2000 DDK. Won’t this document help u?
> >
> >
> >Regards,
> >Chaitanya
> >
> >
> >—
> >You are currently subscribed to ntdev as: xxxxx@mindspring.com
> >To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
> —
> David Feustel
> Fort Wayne, Indiana
> 219-483-1857 (voice)
>
> xxxxx@mindspring.com
> http://www.mindspring.com/~dfeustel
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@cmcltd.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> stream, and do reads and writes. For that matter, the concept of block
devices and stream devices seems like it fits most devices.
Most, but not USB or 1394 with their isochronous traffic. Isochronous real-
time traffic cannot be handled OK in this good old UNIX paradigm of block
and char devices.
Max
At 08:56 PM 3/31/00 +0400, Maxim S. Shatskih wrote:
> stream, and do reads and writes. For that matter, the concept of block
> devices and stream devices seems like it fits most devices.Most, but not USB or 1394 with their isochronous traffic. Isochronous real-
time traffic cannot be handled OK in this good old UNIX paradigm of block
and char devices.
Just for my education, can you explain why this is, in detail? A receiving
program could queue up a bunch of read requests (overlapped) and a sending
program just queues up a bunch of writes. The data flows at the rate of the
isochronous channel, and reads don’t always return as many bytes as you
asked for. Actually, the current overlapped read API already has two
parallel channels, the data channel and the info channel (status and number
of bytes transferred).
I’m assuming the generic read/write verbs have a way to do asynchronous
completion (like is already present in the Win32 API). I should probably
clarify myself, that I believe a single read and write API could exists
that worked on everything, and that generic API might be a bit more complex
than the Unix read/write (the current Win32 API with overlapped support
might be sufficient).
I’m always open to hearing why something is impossible, but I’m also
interested in trying to prevent complexity expansion.
> I’m always open to hearing why something is impossible, but I’m also
interested in trying to prevent complexity expansion.
ISOCH_ATTACH_BUFFERS request allows you to specify much more
additional information than a read request.
But you’re right in the main point - they could make the 1394 stack’s
class
IOCTL to be callable from user mode.
Max