Hi Zac. > Maybe would be a good idea to write system-dependent path syntax > checking functions. Something like 'pdf_fsys_posix_path_name_p' and > 'pdf_fsys_w32_path_name_p'. What do you think? > I think it would be a good idea. I will look into it.
Thanks. Windows is Unicode safe, they comply from UTF-7 up to UTF-32. Pre-Win2K NT platforms (most notably NT 4) do use UCS-2 so that can be incompatible. Note that we should be able to manage that kind of systems too. As a solution (discussed between myself and jemarch), a work around is to always ask Windows to convert the string to UTF-16 since this is Windows preferred internal representation of data in unicode. The text module can do that, using 'pdf_text_get_unicode' instead of 'pdf_text_get_host'. > How do 'FindFirstFile' manages relative paths? What is the "default" > volume used if the path does not contain a volume specification? Do it > support "device" filenames such as PRN? > Relative paths are handled by the FindFirstFile facilities. I'm almost positive the default volume used is that of the CWD. Regarding device filenames, I'm unsure. Please check the volume issue. If you are right then it is not a problem: the POSIX functions do the same when applying pwd.
