[fpc-devel] Console IO revisited
Sorry if this is already picked up as it IMHO should have been. I missed some mails due to a server crash. Today I encountered a similar issue with using threadvars for the input, output and err variables in system when trying to use the input as a win32 sync handle with the CreateFile API. Fails miserably. This is specified in the windows API documentation, but is broken in FPC because the IO are not global to a process but threadvar. This is a mistake! (without due explanation, not from the point of FPC developers, but from the point of view of OS development Checkout for example: http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx It becomes obvious, especially in the case of (the recommended) overlapped IO for std streams that this is totally broken in FPC. Also, as I stated before, for the same reason it breaks the Posix compliance. AFAIK it also would break any GCC/C++ code for OS's that contain a Posix subsystem and you would want to translate some code for. I therefore ask again to change the Threadvars for console IO to vars. It breaks not only what windows expects, but also what most nixes expect. The only somewhat useful comments I have seen regarding to this in our previous discussion are FPC specific! work-arounds. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
On 3-12-2010 13:22, Thaddy wrote: --- CreateFile; /lpFileName/ Use the CONIN$ value to specify console input. Use the CONOUT$ value to specify console output. CONIN$ gets a handle to the console input buffer, even if the *SetStdHandle* http://msdn.microsoft.com/en-us/library/ms686244%28v=VS.85%29.aspx function redirects the standard input handle. To get the standard input handle, use the *GetStdHandle* http://msdn.microsoft.com/en-us/library/ms683231%28v=VS.85%29.aspxfunction. CONOUT$ gets a handle to the active screen buffer, even if *SetStdHandle* http://msdn.microsoft.com/en-us/library/ms686244%28v=VS.85%29.aspxredirects the standard output handle. To get the standard output handle, use *GetStdHandle* http://msdn.microsoft.com/en-us/library/ms683231%28v=VS.85%29.aspx. // This behaveour is broken in FPC without intervention from the programmer in a very unusual way. (i.e. without hacks) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
On Fri, 3 Dec 2010, Thaddy wrote: Sorry if this is already picked up as it IMHO should have been. I missed some mails due to a server crash. Today I encountered a similar issue with using threadvars for the input, output and err variables in system when trying to use the input as a win32 sync handle with the CreateFile API. Fails miserably. This is specified in the windows API documentation, but is broken in FPC because the IO are not global to a process but threadvar. Would you care to explain this ? The variables Input, Output and StdErr may be threadvars, but they share a single common OS handle. So any OS-specific functions should still work if you are using the handles. If you are attempting to translate some concepts that work on handles to Pascal files, then you should be warned that they will fail in each case, because file handling works with internal buffers - threadvars or not. The variables Input, Output and StdErr have been made threadvars so the basic pascal functions ReadLn and Writeln are thread-safe. As for Posix: Pascal is not Posix; We define the RTL as we see fit; So invoking non-posix compliance is not an argument. So please explain your problem properly and detailed. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
On 3-12-2010 13:38, Michael Van Canneyt wrote: On Fri, 3 Dec 2010, Thaddy wrote: Sorry if this is already picked up as it IMHO should have been. I missed some mails due to a server crash. Today I encountered a similar issue with using threadvars for the input, output and err variables in system when trying to use the input as a win32 sync handle with the CreateFile API. Fails miserably. This is specified in the windows API documentation, but is broken in FPC because the IO are not global to a process but threadvar. Would you care to explain this ? The variables Input, Output and StdErr may be threadvars, but they share a single common OS handle. So any OS-specific functions should still work if you are using the handles. No they do not, see my previous post, hence my problem. Mind the words even if in the win api doc cit. I may be * very * wrong, but it simply doesn't work as expected. Under Delphi it works as expected and in line with the API documentation. I am investigating Linux (Ubuntu and my own woof builds) to get a similar example working without workarounds. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
On Fri, 3 Dec 2010, Thaddy wrote: On 3-12-2010 13:22, Thaddy wrote: --- CreateFile; lpFileName Use the CONIN$ value to specify console input. Use the CONOUT$ value to specify console output. CONIN$ gets a handle to the console input buffer, even if the SetStdHandle function redirects the standard input handle. To get the standard input handle, use the GetStdHandlefunction. CONOUT$ gets a handle to the active screen buffer, even if SetStdHandleredirects the standard output handle. To get the standard output handle, use GetStdHandle. This behaveour is broken in FPC without intervention from the programmer in a very unusual way. (i.e. without hacks) HOW is it broken ? If you use the CreateFile() function from the windows unit, you are directly speaking to the operating system, FPC in no way interferes with that. If you think that these functions or their description somehow apply or transfer to the standard Pascal Input, Output and stdErr text variables, then you are mistaken. The rules for these variables are governed by the pascal standard, not by the operating system. If you want the functionality of the CreateFile() function, you must use Windows, and only windows, functions on the file handles thus obtained. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
On Fri, 3 Dec 2010, Thaddy wrote: On 3-12-2010 13:38, Michael Van Canneyt wrote: On Fri, 3 Dec 2010, Thaddy wrote: Sorry if this is already picked up as it IMHO should have been. I missed some mails due to a server crash. Today I encountered a similar issue with using threadvars for the input, output and err variables in system when trying to use the input as a win32 sync handle with the CreateFile API. Fails miserably. This is specified in the windows API documentation, but is broken in FPC because the IO are not global to a process but threadvar. Would you care to explain this ? The variables Input, Output and StdErr may be threadvars, but they share a single common OS handle. So any OS-specific functions should still work if you are using the handles. No they do not, see my previous post, hence my problem. Mind the words even if in the win api doc cit. I may be * very * wrong, but it simply doesn't work as expected. Under Delphi it works as expected and in line with the API documentation. I am investigating Linux (Ubuntu and my own woof builds) to get a similar example working without workarounds. As said in my other mail: The behaviour of Input, Output, StdErr is not governed by OS rules, but by the pascal standard. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
Note the console IO functions are *as I read it and can show it* are supposed NOT to share a single handle. Only the use of the std file names should guarantee a common handle and that is where FPC fails my tests. The redirection for other purposes on a OS level call under windows and posix will give you a handle but consequently will fail on the standard file names. Or am I wrong? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
On 3-12-2010 13:52, Michael Van Canneyt wrote: As said in my other mail: The behaviour of Input, Output, StdErr is not governed by OS rules, but by the pascal standard. Michael. My understanding has always been that the PASCAL syntax allowed for console IO in a way that encapsulates the console IO features that an OS supports. Although it might very well be PASCAL was the first high level language to support it.. Wait! Oh, no it's not, that was Fortran (port(5); and port(6); ;-) ) since the 50's. By today's standards I suppose you should read it like that. But I will give up my efforts if nobody else cares... :-) It just seems strange and a wrong way of doing things. But I agree, only from an OS perspective, not from the language point of view. In the context of OS's CONIN$ etc are rather common beasts and might have - a lot: windows 1 f.e - something to do with Pascal history, but not with the language as such anymore. In the case of historic arguments I see no reason to change over 40 year old expected language behaveour anyway :-) If you all say no, I will live with it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
Op Fri, 3 Dec 2010, schreef Thaddy: If you all say no, I will live with it. Could you maybe specify what you want to achieve and in what way FPC requires you to use workaround hacks? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
Am 03.12.2010 13:22, schrieb Thaddy: Sorry if this is already picked up as it IMHO should have been. I missed some mails due to a server crash. Today I encountered a similar issue with using threadvars for the input, output and err variables in system when trying to use the input as a win32 sync handle with the CreateFile API. Fails miserably. This is specified in the windows API documentation, but is broken in FPC because the IO are not global to a process but threadvar. This is a mistake! (without due explanation, not from the point of FPC developers, but from the point of view of OS development Checkout for example: http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx It becomes obvious, especially in the case of (the recommended) overlapped IO for std streams that this is totally broken in FPC. Also, as I stated before, for the same reason it breaks the Posix compliance. AFAIK it also would break any GCC/C++ code for OS's that contain a Posix subsystem and you would want to translate some code for. I therefore ask again to change the Threadvars for console IO to vars. It breaks not only what windows expects, but also what most nixes expect. The only somewhat useful comments I have seen regarding to this in our previous discussion are FPC specific! work-arounds. Would you mind sharing some example Pascal code for what you're trying to do? Maybe you are just missing something (yes, I have read the other mails in this thread). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
Am 03.12.2010 16:11, schrieb Thaddy: On 3-12-2010 15:50, Daniël Mantione wrote: Could you maybe specify what you want to achieve and in what way FPC requires you to use workaround hacks? Daniël Yes, In FPC the console IO is *always* redirected, be it through a handle or a named file. The named file is expected to be independent of redirection. The handle not. Handle copying or inheritance The handles are copied but never used. InitThread reinitializes the std i/o handles for each thread? See e.g. rtl/win/syswin.inc:173 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
Op Fri, 3 Dec 2010, schreef Thaddy: On 3-12-2010 15:50, Daniël Mantione wrote: Could you maybe specify what you want to achieve and in what way FPC requires you to use workaround hacks? Daniël Yes, In FPC the console IO is *always* redirected, be it through a handle or a named file. I don't understand what you mean here. The named file is expected to be independent of redirection. The handle not. Handle copying or inheritance doesn't matter in this case. The 'CONXXX' should always point to one and the same. Without hacks this is not possible in the current implementation. CONXXX != ( sorry, not) the vars Input, output etc. Okay, so you are saying that an assign(input,'CONXXX') results into dual handles? What is the reason you do not use the standard assign(input,''), to attach to stdio? I.e. is there a good reason why you are using CONXXX? At least in winapi speak. (or similar with Posix). But Posix doesn't have a CONXXX equivalent?! And these refer to OS interfaces, not languages. But as I confess, I might be wrong. Show me. Michael has a point of view from the language perspective, which is historically almost correct. My view is it has been superseded by OS's through history. Oh my, I just promised I consider the prevailing opinion as acceptable ;-) I still would like to know what you are trying to achieve. You got closer, but I still don't get the reason why you want to work with CONXXX Also, you understand that making stdio thread-safe without threadvars is a huge change that requires a lot of time investment? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
Thaddy wrote: On 3-12-2010 13:52, Michael Van Canneyt wrote: As said in my other mail: The behaviour of Input, Output, StdErr is not governed by OS rules, but by the pascal standard. Michael. My understanding has always been that the PASCAL syntax allowed for console IO in a way that encapsulates the console IO features that an OS supports. My understanding is that you are wrong. For those program parameters that are file variables, the binding is implementation defined. [JW, 3rd edition, p200]. The effect of applying the predeclared procedure Reset or Rewrite to either Input or Output is implementation-defined. [ibid, p129]. Note further that JW does not make provision for binding a file variable to a named file or device, or for a non-blocking keyboard read. Every description of classical Pascal that I have seen makes it abundantly clear that Wirth considered that the mapping between INPUT/OUTPUT and whatever physical or logical devices were available was outside his remit. I'd particularly point out that JW entertains the possibility that they could be mapped to tapes, card readers or any of the other weird and wonderful I/O devices available when the language was defined. So, FPC might attempt to encapsulate the file handling capabilities of current OSes, which are very different from what were available when Wirth designed Pascal. However at that point I'd suggest that you listen attentively to what FPC's developers tell you, rather than expecting them to listen attentively to you. Written as an exasperated non-developer, -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
