Printable View
Ok i've done some googling and some searching here and come up with nothing.
I've found a bunch of stuff at msdn but i can't make head nor tails of it, does anyone know of resources detailing how to write to a cdr? Even some simple code examples perhaps? Thanks.
Wow!, writing to a cd? that's some ****!
Doub't if youlle get anything working, i even can't get nero or
cdclone to burn my files, but writing something yourself!, im
affraid this to complicated too find a tutorial for.
Maybe you're in luck and anyone on this board has done that
(and got hired by a company for his 7331 skillz)
well i'd assume it wouldn't be too incredibly complicated. I assume it would be as if I were to write to a floppy, i'd set up a table of sector sizes and number of sectors etc.
With a cd i'd need to work with the TOC (table of contents) on top of that....mostly need to know how to send signals to the hardware, etc. Like i said if no one can get tutorials that's fine, code snippets are cool too. :)
Open Source CD Writing program, it's for linux however
Here
heres something in addition:
http://sourceforge.net/projects/k3b/
my target is a win 9x machine, i'll give that a good once over. I right off the bat don't like the extensive use of all the open source stuff he uses (ie: blade and lame, i have both but i want to learn how to write closer to the hardware level, not how to call functions from those dlls). Might produce something good, i emailed the author asking for some prodding in the right direction as far as learning how to make the program goes.
Thanks.
I'm guessing here, haven't used this...
But windows has shell extension commands for things like copy file etc.. Got a feeling if you use these to copy onto the CD, it might work. If it does let me know. I'll be having to solve this problem shortly also.
Have a look at: SHFileOperation in MSDN.
>If there's a driver installed for the CDR drive that supports write operations, the kernel will call the according function automatically if you attempt to write to it using a system call
You would think so.
But my CD writer does not seem support to system call writes, but supports Windows Exploder file operations.
I think I understand what you meant. However, I'm not saying that I know what answer is, because I really don't - I was simply taking a guess, based on the following:
When I copy files to the CD using Explorer, they are copied to a temporary folder instead & Windows tells me there are files waiting to be copied to the CD. If I try to write a file to the CD from an application, I get a permission denied error. Most CD writers seem to work this in Windows now, although I have an ancient CD writer on my old computer which does support system call writes.
So I don't know. I am not expert on CD drivers or CD hardware. I was just guessing that this is the problem Waldo2k2 having & was guessing that the CD 'driver' (if you can call it that) has hooked into the Windows Shell, rather than providing system level support.
>but supports Windows Exploder file operations.
>What's that?
It was meant to be a joke. Forget it.
>Yes, I got the joke part
Oh. Sorry.
>Eventually it uses the same system calls as any other application, doesn't it?
I think that's a good question. All I can say is that MS provide API commands for things like file copy. Why would they do this if you have access to such calls any way? So I don't know, I'm not an expert on Windows shell extensions? I would be interested to learn what is really happening.
As I understand it...
Windows XP has native support for CDR, but Windows 98 does not. I don't know about Windows ME.
So, Windows XP has a CDR virtual device driver (VXD) and API functions.
With older versions of Windows, you have to know how to interface with the vendor's driver (or write you own).
A VXD is aan interface, (or "translator"). Both the application and the manufacturer's driver know how to communicate with the VXD.
Without this support, the application itself has to know how to communicate with many different devices. For example, in the DOS days, when you bought a word processor program it would come with a bunch of printer drivers (written by the company that wrote the word processor) and you had to install the appropriate one for that application and your particular printer. Now if you write a word processing program, you only have to interface with the virtual device driver... you don't care if the printer is parallel, USB, or over a network... the OS takes care of that. You only install one driver to interface with the OS. Of course, the printer manufacturer's driver has to 'hook' to the VXD too. The down side is that printer manufacturer's no longer publish the details of their protocols. (i.e. how to change the font size, etc.)
Bottom line - For Windows XP the answer lies with Microsoft (I think you'd need an up-to-date compiler to access the new APIs too). Otherwise you'd have to try the CDR drive manufacturer.
thanks everyone.
I guess i'll target xp then.
My comp was down for a few days so i didn't get to respond to any of these....thinking of buying xp pro upgrade for my dad for christmas so i'll be able to do it then.