ISO-Image einer CDDA mit CreateFile und ReadFile möglich?

[OldGrumpy]

Beim Lesen von Blockdevices muss die Leseposition eine Blockgrenze (bzw. der Anfang eines Blocks) sein, mittendrin anfangen zu lesen klappt nicht. Und weil in deiner Funktion oben (function ReadCDAudioSector) am Anfang mit CB_CDROMSECTOR gearbeitet wird, vermute ich mal dass da mit 2048 statt 2352 bzw. 2336 (je nach Trackmode) gerechnet wird - Der Lesezugriff schlägt dann auf die eine oder andere Art fehl. Beim direkten Lesen von USB-Devices muss darüber hinaus noch der Puffer im Speicher auf Speicherseiten aligned sein, so einen passend plazierten Puffer erhaelt man mittels VirtualAlloc. Ich hatte vor geraumer Zeit auch mal mit diesen Sourcen rumgespielt, dann aber irgendwann keine Zeit mehr gehabt, alles hinzubiegen.

[himitsu]

Zitat von OldGrumpy:

Beim direkten Lesen von USB-Devices muss darüber hinaus noch der Puffer im Speicher auf Speicherseiten aligned sein, so einen passend plazierten Puffer erhaelt man mittels VirtualAlloc. Ich hatte vor geraumer Zeit auch mal mit diesen Sourcen rumgespielt, dann aber irgendwann keine Zeit mehr gehabt, alles hinzubiegen.

Dem ist ganz nicht so, daß kann ich dir inzwischen bestätigen ... jedenfalls nicht in "aktuellen" Systemen wie XP und 2000.

Laut Muetze1 (ich hoffe er war es) könnte das daran liegen, daß zum Auslesen der Speicher in 'nem bestimmten Bereich ganz weit vorn im RAM liegen muß und demnach Windows wohl über 'nen eigenen Zwischenspeicher geht und dann die Daten erst und deinen Speicher rüberkopiert werden, wobei dort egal ist wo dieser Speicher rumliegt.
Oder so in etwa ... jedenfalls geht es bei mir auch so, ohne aligned Speicher ... ist schon praktisch, wenn man da z.B. auch einfach etwas aus'm Stack nutzen kann und sich die Resourcenschutzblöcke, samt Speicherreservierung/-freigabe spart.

Aber Schaden kann es ja nie

[Muetze1]

Zitat von himitsu:

Zitat von OldGrumpy:

Beim direkten Lesen von USB-Devices muss darüber hinaus noch der Puffer im Speicher auf Speicherseiten aligned sein, so einen passend plazierten Puffer erhaelt man mittels VirtualAlloc. Ich hatte vor geraumer Zeit auch mal mit diesen Sourcen rumgespielt, dann aber irgendwann keine Zeit mehr gehabt, alles hinzubiegen.

Dem ist ganz nicht so, daß kann ich dir inzwischen bestätigen ... jedenfalls nicht in "aktuellen" Systemen wie XP und 2000.

Laut Muetze1 (ich hoffe er war es) könnte das daran liegen, daß zum Auslesen der Speicher in 'nem bestimmten Bereich ganz weit vorn im RAM liegen muß und demnach Windows wohl über 'nen eigenen Zwischenspeicher geht und dann die Daten erst und deinen Speicher rüberkopiert werden, wobei dort egal ist wo dieser Speicher rumliegt.
Oder so in etwa ... jedenfalls geht es bei mir auch so, ohne aligned Speicher ... ist schon praktisch, wenn man da z.B. auch einfach etwas aus'm Stack nutzen kann und sich die Resourcenschutzblöcke, samt Speicherreservierung/-freigabe spart.

Meine Aussage bezog auf den DMA Transfer, wobei der DMA Baustein keine "grossen" Adressen abkann und nur im unteren 1 MB arbeitet. Daher muss bei der DMA Übertragung der Speicher dort unten liegen. Unter Windows sorgt die WinAPI dafür und kopiert von diesem weiter - und dabei kommt dann kein DMA mehr zum Einsatz und die Adressen können auch "quer" liegen - dieses macht nur wieder den Zugriff der CPU langsamer durch die extra-cyclen die die CPU beim Data-fetch drehen muss...

Virtualisierungen im Sinne des V86 und Protected Modes gelten für die CPU und den Dingen die darauf ablaufen, der DMA Controller hängt aber ausserhalb der CPU im System und kümmert sich soweit selbstständig um die Datenübertragung kann nur mit physikalischen Adressen - und sein Register ist für diese beschränkt.

[OldGrumpy]

Zitat von himitsu:

Zitat von OldGrumpy:

Beim direkten Lesen von USB-Devices muss darüber hinaus noch der Puffer im Speicher auf Speicherseiten aligned sein, so einen passend plazierten Puffer erhaelt man mittels VirtualAlloc. Ich hatte vor geraumer Zeit auch mal mit diesen Sourcen rumgespielt, dann aber irgendwann keine Zeit mehr gehabt, alles hinzubiegen.

Dem ist ganz nicht so, daß kann ich dir inzwischen bestätigen ... jedenfalls nicht in "aktuellen" Systemen wie XP und 2000.

Sicher? Ich hatte nämlich vor gar nicht mal so langer Zeit genau so einen Fall: Memorycard im USB-Cardreader als physical device zum Lesen geöffnet. Lesen klappte auch super, nur stand im Puffer jede Menge Unsinn drin. Nach langem googlen hatte ich dann in der MSDN einen entsprechenden Hinweis gefunden. Nach Anlegen des Puffers mit VirtualAlloc funktionierte das Lesen dann einwandfrei...

Ich schau mal ob ich die Seite in der MSDN wiederfinde.

Edit: Hier isses: [msdn]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/readfile.asp[/msdn]

Allerdings hatte ich es etwas anders in Erinnerung, der Puffer muss sector-aligned sein. Da die Pagegröße praktisch immer ein Vielfaches der Sektorgröße ist, erfüllt das Alignment auf Pages den gleichen Zweck

Zitat von MSDN:

File access must begin at byte offsets within the file that are integer multiples of the volume sector size. To determine the sector size of a volume, call the GetDiskFreeSpace function.
File access must be for numbers of bytes that are integer multiples of the volume sector size. For example, if the sector size is 512 bytes, an application can request read and write operations of 512, 1024, 1536, or 2048 bytes, but not of 335, 981, or 7171 bytes.
Buffer addresses for read and write operations must be sector aligned (that is, aligned on addresses in memory that are integer multiples of the volume sector size).
One way to sector align buffers is to use the VirtualAlloc function to allocate the buffers. This function allocates memory that is aligned on addresses that are integer multiples of the system page size. Because both page and volume sector sizes are powers of 2 (two), memory aligned by multiples of the system page size is also aligned by multiples of the volume sector size.

[himitsu]

@Muetze1: OK, wenn man dat so sieht, dann könnte es hinkommen

Zitat von OldGrumpy:

Sicher? Ich hatte nämlich vor gar nicht mal so langer Zeit genau so einen Fall: Memorycard im USB-Cardreader als physical device zum Lesen geöffnet. Lesen klappte auch super, nur stand im Puffer jede Menge Unsinn drin.

Jo, denn ich hatte es erst selber nur über nicht ausgerichteten Speicher gemacht und dann meinte Muetze1 der Speicher müsse ausgerichtet werden ... aber es ging/geht auch so. ^^

Bei ReadFile/WriteFile und beim DMA-Trasfer ... was an Daten drin stand war eigentlich ganz OK

[OldGrumpy]

Vielleicht hattest Du einfach nur Glück und Deine Puffer waren zufällig halt entsprechend aligned Zumindest unter W2K (hab es später nicht mehr auf XP getestet, da ich es für sinnvoller hielt, eine Lösung zu implementieren die unter beiden Systemen funktioniert...) gehts mit krummen Werten definitiv nicht gut. Von mir aus kann ich gerne mal den Source rauswühlen und Samples posten

[Garfield]

Entschuldigung für die späte Antwort. Ich war ein paar Wochen auf Montage und hatte keinen Internetzugang.

Zitat von himitsu:

Was passiert wohl, wenn du versuchst eine schreibgeschützte CD mit Schreibrechten zu öffnen

Meiner Ansicht nach wird nicht die schreibgeschützte CD sondern das Gerät geöffnet. Falls der Benutzer keine Schreibrechte bzw in diesem Fall keine Brennrechte besitzt, erhält er auch kein gültiges Handle. Des weiteren sind für einige Funktionen wie im vorliegenden Fall Schreibrechte erforderlich. Deshalb arbeitet zum Beispiel VCDEasy mit SPTI nur unter Administratorkonten.

Zitat von himitsu:

Mal nachgesehen, ob die Sektoren wirklich 4096 Byte groß sind?

Diese Größe bezieht sich auf die Nutzdaten von zwei Datensektoren. Ist aber eher unwichtig, weil der Source funktioniert.

FILE_FLAG_NO_BUFFERING werde ich mal versuchen,

Zitat von OldGrumpy:

... Und weil in deiner Funktion oben (function ReadCDAudioSector) am Anfang mit CB_CDROMSECTOR gearbeitet wird, vermute ich mal dass da mit 2048 statt 2352 bzw. 2336 (je nach Trackmode) gerechnet wird - Der Lesezugriff schlägt dann auf die eine oder andere Art fehl.

Die Sektoren sind auf jeder CD gleich groß und unterscheiden sich lediglich im Aufbau. 2048, 2352 und 2336 sind dabei jeweils die Größe der Nutzdaten. AudioCD zum Beispiel: http://de.wikipedia.org/wiki/Audio-CD

In allen Sourcen, welche ich fand, wurde bei der Positionierung mit der Größe der Nutzdaten von Datensektoren gerechnet. Anschließend wird der Typ des Sektors eingestellt und die tatsächliche Größe der Nutzdaten gelesen.