Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Windows 2000 API for IEEE 1394

OSR_Community_UserOSR_Community_User Member Posts: 110,217
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?

Thanks.
---
David Feustel
Fort Wayne, Indiana
219-483-1857 (voice)

[email protected]
http://www.mindspring.com/~dfeustel

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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: [email protected]
    >To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    David Feustel
    Fort Wayne, Indiana
    219-483-1857 (voice)

    [email protected]
    http://www.mindspring.com/~dfeustel
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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:[email protected]]
    > Sent: Wednesday, March 29, 2000 7:47 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Re: Windows 2000 API for IEEE 1394
    >
    >
    > 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: [email protected]
    > >To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ---
    > David Feustel
    > Fort Wayne, Indiana
    > 219-483-1857 (voice)
    >
    > [email protected]
    > http://www.mindspring.com/~dfeustel
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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.

    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)

    [email protected]
    http://www.mindspring.com/~dfeustel
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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:[email protected]]
    > Sent: Wednesday, March 29, 2000 10:45 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Re: Windows 2000 API for IEEE 1394
    >
    >
    > 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.
    >
    > 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)
    >
    > [email protected]
    > http://www.mindspring.com/~dfeustel
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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.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.

    ---
    David Feustel
    Fort Wayne, Indiana
    219-483-1857 (voice)

    [email protected]
    http://www.mindspring.com/~dfeustel
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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.

    - Jan
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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:[email protected]]
    > Sent: Wednesday, March 29, 2000 4:03 PM
    > To: NT Developers Interest List
    > Subject: [ntdev] Re: Windows 2000 API for IEEE 1394
    >
    >
    > 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.
    >
    > - Jan
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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)

    [email protected]
    http://www.mindspring.com/~dfeustel
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    WinZip will extract cab files. Also, doesn't w2k explorer allow browsing of
    cab files?

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]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)
    >
    > [email protected]
    > http://www.mindspring.com/~dfeustel
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    "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 1394
    >
    > WinZip will extract cab files. Also, doesn't w2k explorer allow browsing
    > of
    > cab files?
    >
    > > -----Original Message-----
    > > From: [email protected]
    > > [mailto:[email protected]]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)
    > >
    > > [email protected]
    > > http://www.mindspring.com/~dfeustel
    > >
    > >
    > >
    > > ---
    > > You are currently subscribed to ntdev as: [email protected]
    > > To unsubscribe send a blank email to $subst('Email.Unsub')
    > >
    > >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Where is the 1394.dll and its associated documentation to be found?

    At 10:06 AM 03/30/2000 +0530, "Bhaava Chaitanya Kancherla" <[email protected]>
    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: [email protected]
    >To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    David Feustel
    Fort Wayne, Indiana
    219-483-1857 (voice)

    [email protected]
    http://www.mindspring.com/~dfeustel
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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.

    When I use Winzip to extract the files, I get the 51 files created,
    but when I examine the file content, almost all of the files include
    comments indicating that the filename is something else (.c,.h, etc)
    Some files seem to contain only fragments to be included in other files.
    In addtion, some filenames occur more than once. That suggests to
    me that, properly extracted, the files with identical basenames would
    be placed in distinct directories, which feat I have so far been unable
    to achieve.
    ---
    David Feustel
    Fort Wayne, Indiana
    219-483-1857 (voice)

    [email protected]
    http://www.mindspring.com/~dfeustel
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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 <[email protected]>
    To: NT Developers Interest List <[email protected]>
    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"
    <[email protected]>
    > 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: [email protected]
    > >To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ---
    > David Feustel
    > Fort Wayne, Indiana
    > 219-483-1857 (voice)
    >
    > [email protected]
    > http://www.mindspring.com/~dfeustel
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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.

    - Jan
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Internals & Software Drivers 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online
Developing Minifilters 23 May 2022 Live, Online
Writing WDF Drivers 12 September 2022 Live, Online