Re: Reading contents of an ISO file

On Thu, 29 Nov 2007 06:42:25 -0800, Steve Welborn
<swelborn2001YAHOO.COM>
wrote:

>Thank you for the resource. Seems like a great site.
>
>
>>I didn't have much luck finding the ISO file format
specification.
>>However, for future reference, here's my favorite
file specification
format
>>site:
>>http://www.wotsit.org/
>>
>>Thanks,
>>Mike
>
>>On Nov 28, 2007 1:21 PM, Steve Welborn
<swelborn2001yahoo.com> wrote:
>
>> I am just creating the extension for learn
>> Thanks for the reply Barry.
>>
>> I am just creating the extension for learning
purposes. I am aware that
it
>> is not recommended by MS nor supported.
>>
>> I havent started on the ISO viewing yet. I am not
really sure where to
>> begin. I did a few googles to see if I could find
some sample code but
>> nothing was found.
>>
>> So mainly the difficulty is opening the iso file as
a stream or whatever
>> and spit the contents out into a listview.
>>
>> Thats really all I want. To be able to view the
contents of the ISO and
>> put it in my listview. I already have something
that extracts it.
>>
>> any suggestions?
>>
>> Steve
>>
>>
>>
>> Steve Welborn <swelborn2001YAHOO.COM> wrote:
>>
>> > Hello everyone. I am in the process of writing
an Extension to the
>> Windows Shell
>> >
>> > My environment will be C# and Windows 2003 and
up.
>>
>> You shouldn't write in-process extensions to the
shell in managed code,
>> because it causes the shell to load a specific
version of the .NET
>> runtime into the shell process. This creates an
ordering dependency if
>> there are multiple shell extensions that target
different .NET runtimes.
>>
>> For example, if there are two shell extensions,
E_11 (targeting 1.1) and
>> E_20 (targeting 2.0) and E_11 gets loaded before
E_20, then E_20 will
>> fail to load because you can't have more than one
version of the .NET
>> runtime in a single process.
>>
>> > and although I have majority of it complete I
am having problems being
>> able to view the contents of an .iso file. With my
extension I will be
>> working with iso files and a few other formats.
>> >
>> > Can someone set me in the right direction as
far as how to view/output
>> the contents of an iso file?
>>
>> I'm not 100% sure what your difficulty is. Is it
the ISO format itself?
>> If I was interested in that, I'd look at the
ISO9660 file system driver
>> in Linux.
>>
>> -- Barry
>>
>> --
>> http://barrkel.blogspot.
com/
>>
>> ----- Original Message ----
>> From: Steve Welborn <swelborn2001YAHOO.COM>
>> To: ADVANCED-DOTNETDISCUSS.DEVELOP.COM
>> Sent: Monday, November 26, 2007 1:25:23 PM
>> Subject: [ADVANCED-DOTNET] Reading contents of an
ISO file
>>
>>
>> Hello everyone. I am in the process of writing an
Extension to the
>>  Windows Shell and although I have majority of it
complete I am having
>>  problems being able to view the contents of an
.iso file. With my
>> extension
>>  I will be working with iso files and a few other
formats.
>>
>> Can someone set me in the right direction as far as
how to view/output
>>  the contents of an iso file?
>>
>> My environment will be C# and Windows 2003 and up.
>>
>> Thank you.
>>
>> Steve
>>
>>
>>
>>
>>
>>
____________________________________________________________
________________
________
>> Get easy, one-click access to your favorites.
>> Make Yahoo! your homepage.
>> http://www.yahoo.com/r/hs
>>
>> ===================================
>> This list is hosted by DevelopMentor(R)  http://www.develop.com
>>
>> View archives and manage your subscription(s) at
>>  http://discuss.develop.com

>>
>>
>>
>>
>>
>>
>>
>>
____________________________________________________________
________________
________
>> Never miss a thing.  Make Yahoo your home page.
>> http://www.yahoo.com/r/hs
>>
>> ===================================
>>  This list is hosted by DevelopMentor(R)  http://www.develop.com
>>
>> View archives and manage your subscription(s) at
>> http://discuss.develop.com

>>
>
>
>
____________________________________________________________
________________
________
>Be a better sports nut!  Let your teams follow you
>with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbM
uh1G1SQtBI7ntAcJ
>
>===================================
>This list is hosted by DevelopMentorŪ  http://www.develop.com
>
>View archives and manage your subscription(s) at http://discuss.develop.com


take a look:
http://en.wikip
edia.org/wiki/ISO_9660


you may also wan to search with google with "iso
format"  and possibly UDF


you will be dealing litlle-endian and/or bi-endian, maong
other thing

why woudl you want  to learn fiel stream with such is beyond
me. I woudl
prefer picking on something more practical, more real life
problem

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

I've got an application (1) running on an SBC pumping data
out over a
System.Net.Sockets.Socket object about every 1/2 second. 
I've got
another application (2) receiving that data.  When the data
comes in to
app 2, the data is parsed and stored into an object and then
an event is
raised telling a form on app 2 that it can do a few things
with that
object (the one that holds the parsed data).

The event handler displays data to a window (which needs to
be done
immediately) of app 2 and also attempts to write the data to
a database.
Writing to the database might be a problem if there is some
sort of
connection issue, etc.

I don't want to be held up in the event handler because the
database
access couldn't be performed.  So I figured I could just
open up another
thread to do the database access.  However I worry about
threads
stacking up that couldn't finish (suppose the db time out is
10 seconds
- by the time a timeout error occurs, I might have 19 more
writes
pending on active threads).  

It seems like there ought to be a better way to do this -
maybe
something like starting a thread that lasts as long as the
app does that
is solely used for the database writing.  It could know
whether it is
connected to the db or not and keep track of the writes it
was supposed
to do, etc.

Is this a legitimate way to make this functionality?  Is
there a better
way?

(aside - this issue started with all the processing and db
access in the
socket data handler.  I noticed that if something held up
the writing to
the db in app 2, it actually cause issues with app 1 not
being able to
pump out its data over the socket).

Peter

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Peter Osucha <PeterPROTEINDISCOVERY.COM> wrote:

> It seems like there ought to be a better way to do this
- maybe
> something like starting a thread that lasts as long as
the app does that
> is solely used for the database writing.  It could know
whether it is
> connected to the db or not and keep track of the writes
it was supposed
> to do, etc.
> 
> Is this a legitimate way to make this functionality? 
Is there a better
> way?

This is a basic producer-consumer queue. There must be
hundreds of
example implementations out on the net.

> (aside - this issue started with all the processing and
db access in the
> socket data handler.  I noticed that if something held
up the writing to
> the db in app 2, it actually cause issues with app 1
not being able to
> pump out its data over the socket).

Of course. Bear in mind, you may want this behaviour in
certain cases:
if the data is coming in faster than it's being drained from
your queue,
and you don't block so that the sender is forced to wait,
you can
eventually end up running out of memory.

Actually, the problems can start earlier than that: without
request
throttling, you can cross a thrashing threshold, where even
if the
requests back off, the queue fails to clear fast enough
because of e.g.
VM paging.

-- Barry

-- 
http://barrkel.blogspot.
com/

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Thank you Barry, Phil, and Peter.

I'm working on implementing this separate thread processing
now.  I'll
let you know how it goes.

FWIW, app1 is pushing a string of data about 1024 bytes long
every half
second for up to an hour.  App1 runs on a system with no
keyboard/mouse/monitor so it needs to not 'fail' during this
operation -
especially due to something that is really app2's fault.

Peter


-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNETDISCUSS.DEVELOP.COM] On Behalf Of Barry
Kelly
Sent: Wednesday, March 26, 2008 2:15 PM
To: ADVANCED-DOTNETDISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] threads, sockets, db writing

Peter Osucha <PeterPROTEINDISCOVERY.COM> wrote:

> It seems like there ought to be a better way to do this
- maybe
> something like starting a thread that lasts as long as
the app does
that
> is solely used for the database writing.  It could know
whether it is
> connected to the db or not and keep track of the writes
it was
supposed
> to do, etc.
> 
> Is this a legitimate way to make this functionality? 
Is there a
better
> way?

This is a basic producer-consumer queue. There must be
hundreds of
example implementations out on the net.

> (aside - this issue started with all the processing and
db access in
the
> socket data handler.  I noticed that if something held
up the writing
to
> the db in app 2, it actually cause issues with app 1
not being able to
> pump out its data over the socket).

Of course. Bear in mind, you may want this behaviour in
certain cases:
if the data is coming in faster than it's being drained from
your queue,
and you don't block so that the sender is forced to wait,
you can
eventually end up running out of memory.

Actually, the problems can start earlier than that: without
request
throttling, you can cross a thrashing threshold, where even
if the
requests back off, the queue fails to clear fast enough
because of e.g.
VM paging.

-- Barry

-- 
http://barrkel.blogspot.
com/

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Peter Osucha <PeterPROTEINDISCOVERY.COM> wrote:

> FWIW, app1 is pushing a string of data about 1024 bytes
long every half
> second for up to an hour.  App1 runs on a system with
no
> keyboard/mouse/monitor so it needs to not 'fail' during
this operation -
> especially due to something that is really app2's
fault.

http://en.wikipedia.org/wiki/Fallacies_of_Distrib
uted_Computing

Quote:

1. The network is reliable.

In general, App1 should be able to pick up where it left off
if the
network or App2 goes away for a while. This may or may not
be meaningful
for your domain, though.

-- Barry

-- 
http://barrkel.blogspot.
com/

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Thanks, Barry.  And I agree.  Making app1 capable of doing
this right
now is the issue.  

Peter



-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNETDISCUSS.DEVELOP.COM] On Behalf Of Barry
Kelly
Sent: Wednesday, March 26, 2008 4:54 PM
To: ADVANCED-DOTNETDISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] threads, sockets, db writing

Peter Osucha <PeterPROTEINDISCOVERY.COM> wrote:

> FWIW, app1 is pushing a string of data about 1024 bytes
long every
half
> second for up to an hour.  App1 runs on a system with
no
> keyboard/mouse/monitor so it needs to not 'fail' during
this operation
-
> especially due to something that is really app2's
fault.

http://en.wikipedia.org/wiki/Fallacies_of_Distrib
uted_Computing

Quote:

1. The network is reliable.

In general, App1 should be able to pick up where it left off
if the
network or App2 goes away for a while. This may or may not
be meaningful
for your domain, though.

-- Barry

-- 
http://barrkel.blogspot.
com/

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Thanks, Barry.  And I agree.  Making app1 capable of doing
this right
now is the issue.  

Peter



-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNETDISCUSS.DEVELOP.COM] On Behalf Of Barry
Kelly
Sent: Wednesday, March 26, 2008 4:54 PM
To: ADVANCED-DOTNETDISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] threads, sockets, db writing

Peter Osucha <PeterPROTEINDISCOVERY.COM> wrote:

> FWIW, app1 is pushing a string of data about 1024 bytes
long every
half
> second for up to an hour.  App1 runs on a system with
no
> keyboard/mouse/monitor so it needs to not 'fail' during
this operation
-
> especially due to something that is really app2's
fault.

http://en.wikipedia.org/wiki/Fallacies_of_Distrib
uted_Computing

Quote:

1. The network is reliable.

In general, App1 should be able to pick up where it left off
if the
network or App2 goes away for a while. This may or may not
be meaningful
for your domain, though.

-- Barry

-- 
http://barrkel.blogspot.
com/

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Peter Osucha <PeterPROTEINDISCOVERY.COM> wrote:

> It seems like there ought to be a better way to do this
- maybe
> something like starting a thread that lasts as long as
the app does that
> is solely used for the database writing.  It could know
whether it is
> connected to the db or not and keep track of the writes
it was supposed
> to do, etc.
> 
> Is this a legitimate way to make this functionality? 
Is there a better
> way?

This is a basic producer-consumer queue. There must be
hundreds of
example implementations out on the net.

> (aside - this issue started with all the processing and
db access in the
> socket data handler.  I noticed that if something held
up the writing to
> the db in app 2, it actually cause issues with app 1
not being able to
> pump out its data over the socket).

Of course. Bear in mind, you may want this behaviour in
certain cases:
if the data is coming in faster than it's being drained from
your queue,
and you don't block so that the sender is forced to wait,
you can
eventually end up running out of memory.

Actually, the problems can start earlier than that: without
request
throttling, you can cross a thrashing threshold, where even
if the
requests back off, the queue fails to clear fast enough
because of e.g.
VM paging.

-- Barry

-- 
http://barrkel.blogspot.
com/

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Peter Osucha <PeterPROTEINDISCOVERY.COM> wrote:

> FWIW, app1 is pushing a string of data about 1024 bytes
long every half
> second for up to an hour.  App1 runs on a system with
no
> keyboard/mouse/monitor so it needs to not 'fail' during
this operation -
> especially due to something that is really app2's
fault.

http://en.wikipedia.org/wiki/Fallacies_of_Distrib
uted_Computing

Quote:

1. The network is reliable.

In general, App1 should be able to pick up where it left off
if the
network or App2 goes away for a while. This may or may not
be meaningful
for your domain, though.

-- Barry

-- 
http://barrkel.blogspot.
com/

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Thank you Barry, Phil, and Peter.

I'm working on implementing this separate thread processing
now.  I'll
let you know how it goes.

FWIW, app1 is pushing a string of data about 1024 bytes long
every half
second for up to an hour.  App1 runs on a system with no
keyboard/mouse/monitor so it needs to not 'fail' during this
operation -
especially due to something that is really app2's fault.

Peter


-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNETDISCUSS.DEVELOP.COM] On Behalf Of Barry
Kelly
Sent: Wednesday, March 26, 2008 2:15 PM
To: ADVANCED-DOTNETDISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] threads, sockets, db writing

Peter Osucha <PeterPROTEINDISCOVERY.COM> wrote:

> It seems like there ought to be a better way to do this
- maybe
> something like starting a thread that lasts as long as
the app does
that
> is solely used for the database writing.  It could know
whether it is
> connected to the db or not and keep track of the writes
it was
supposed
> to do, etc.
> 
> Is this a legitimate way to make this functionality? 
Is there a
better
> way?

This is a basic producer-consumer queue. There must be
hundreds of
example implementations out on the net.

> (aside - this issue started with all the processing and
db access in
the
> socket data handler.  I noticed that if something held
up the writing
to
> the db in app 2, it actually cause issues with app 1
not being able to
> pump out its data over the socket).

Of course. Bear in mind, you may want this behaviour in
certain cases:
if the data is coming in faster than it's being drained from
your queue,
and you don't block so that the sender is forced to wait,
you can
eventually end up running out of memory.

Actually, the problems can start earlier than that: without
request
throttling, you can cross a thrashing threshold, where even
if the
requests back off, the queue fails to clear fast enough
because of e.g.
VM paging.

-- Barry

-- 
http://barrkel.blogspot.
com/

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com