Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On Wed, Feb 8, 2012 at 5:28 PM, Craig Peterson cr...@scootersoftware.com wrote: The TNT Unicode controls did it the way you're suggesting, by deciding at runtime, so it is possible, but it would overly complicate the RTL code for an increasingly irrelevant platform. We are big boys, I think that we can handle the imense complexity of 1 if clause in 10 functions. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
Marco van de Voort wrote: In our previous episode, Hans-Peter Diettrich said: IMO a more radical solution is desireable, WRT Win9x. Did anybody test already, how FPC/Lazarus apps behave on such a system, which does not support themes etc., and does not even support Unicode without system updates? I'd split the Win32 target into WinNT (W) and Win9x (A), so that the users can decide whether to support Win9x at all. That depends on decisions still to be made. If we also support 1-byte RTL, it will still be on the level of winNT. But I do think that a win9x vs winnt split is unavoidable in time. Specially since otherwise one gets in the current situation that win9x is occasionally fixed for a release, but in reality constantly broken in between. Presumably lumping pre-W2K NT in with '9x. I'm thinking of http://mantis.freepascal.org/view.php?id=18803 which wasn't really resolved, and which was caused by the return code of a function not implemented in older OSes not being checked. -- 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
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 7-2-2012 12:20, Marco van de Voort wrote: In our previous episode, Hans-Peter Diettrich said: That depends on decisions still to be made. If we also support 1-byte RTL, it will still be on the level of winNT. But I do think that a win9x vs winnt split is unavoidable in time. Specially since otherwise one gets in the current situation that win9x is occasionally fixed for a release, but in reality constantly broken in between. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel I do not think that you will break anything if you make W api or A api default based on platform. This can be switched in the winapi units. That will take little effort, as I explained: we did it already for KOL. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On Mon, February 6, 2012 17:39, Felipe Monteiro de Carvalho wrote: Hello, SysUtils for Windows utilizes only A Windows APIs, while it could use W APIs in Windows NT. The attached patch starts correcting improving the situation. Advantages of the patch: * Allows for unicode file names in TStringList.LoadFromFile if you install paswstrings as the unicode manager. Disadvantages of the patch: * None that I can imagine. Waiting for comments. Regardless of other points raised in the discussion so far and their validity or not, there's one more thing not clear to me. Your patch suggest to use either *A or *W call depending on a condition evaluated at run-time. What's the benefit? If your intention was to keep the programs working with Win9x, this won't help because the program containing unresolved imports wouldn't start anyway. Is there any other reason? Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
2012/2/8 Tomas Hajny xhaj...@hajny.biz: If your intention was to keep the programs working with Win9x, this won't help because the program containing unresolved imports wouldn't start anyway. Is there any other reason? Windows9x has all W functions, Microsoft added them as stubs to avoid this kind of problem. They all exist and they all simply don't do anything so a runtime check is appropriate. There will be no unresolved imports error. We do this in a similar fashion in Lazarus since maybe 5 years without problems and it always ran correctly in Windows 9x. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On Tue, Feb 7, 2012 at 12:07 PM, Marco van de Voort mar...@stack.nl wrote: Note that this might sound useful now ansistring without codepage is still the default string, but if the default string type changes, this is not really useful. You cannot change the default string type without killing the Ansi RTL and destroy backwards compatibility. IOW it is a short term hack with a long time support burden IMHO. I can maintain it. I have here the final solution to Lazarus problems 100 lines of code away, it is a trivial thing to maintain. As long as the Ansi RTL exists, of course. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
Felipe Monteiro de Carvalho schrieb: 2012/2/8 Tomas Hajny xhaj...@hajny.biz: If your intention was to keep the programs working with Win9x, this won't help because the program containing unresolved imports wouldn't start anyway. Is there any other reason? Windows9x has all W functions, Right. Other (post-9x) functions cause more trouble, because these prevent an application from starting at all. That's why Win9x support should either provide workarounds for all API functions, which are not natively available, or (much easier) should exclude all these declarations. One more reason for a dedicated Win9x RTL. Microsoft added them as stubs to avoid this kind of problem. They all exist and they all simply don't do anything They *do* the string conversion, necessary for calling the native functions internally. In Win9x the W functions convert strings into Ansi, on NT the A versions convert strings into WideString. So what's the real benefit of conditionally calling A/W functions, and depending on what? There exist at least two cases, worth more consideration: 1) UTF-8 strings. These require a conversion, regardless of subsequent calls of the A or W function version. Here the knowledge of Windows version can prevent excess A/W conversions inside the OS implementation. 2) Filenames. Here I'm not sure, because even Win9x uses UTF-16 filenames on the disks, and thus the W versions should be preferred. OTOH the MSDN Note that Unicode support on Windows Me/98/95 requires Microsoft Layer for Unicode. suggests that testing for *this* update is the only relevant check, in any A/W calling decision. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On Wed, Feb 8, 2012 at 4:00 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: They *do* the string conversion, necessary for calling the native functions internally. In Win9x the W functions convert strings into Ansi, on NT the A versions convert strings into WideString. So what's the real benefit of conditionally calling A/W functions, and depending on what? I don't have Windows 9x to test so I was just playing it safe by making it work like before for people that don't want UTF-8 and by supporting at least ASCII for people using UTF-8 in Windows 9x, which is pretty much all that it would give us reliably anyway since other chars will break between different computers. The if is also efficient, because in Windows 9x it will avoid a double conversion. Ansi or UTF-8 - UTF-16 - Ansi I was trying to fix my problem while causing no impact for anyone else. But sure, for me it is also fine to go W all the way if someone can test that it works in Windows 9x or if someone does the decision to kill support for it. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 2/8/2012 9:21 AM, Felipe Monteiro de Carvalho wrote:
Windows9x has all W functions,
No it does not. The Microsoft layer for Unicode is a redistributable
DLL that provides W versions of functions and calls the A versions
internally. Win9x does export a bunch of W functions so you can link to
both versions and conditionally call the correct one, but if you
actually try calling the W versions the vast majority will immediately
fail with ERROR_CALL_NOT_IMPLEMENTED.
The platform SDK used to say which platforms supported the W versions,
but that information hasn't been included in quite a while.
For simplicity's sake, assuming continued Win9x support is even
desirable, the RTL should call the generic versions, and Windows.pas
should have {$IFDEF UNICODE} blocks to decide between the A and W
versions. The TNT Unicode controls did it the way you're suggesting, by
deciding at runtime, so it is possible, but it would overly complicate
the RTL code for an increasingly irrelevant platform.
--
Craig Peterson
Scooter Software
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On Mon, Feb 6, 2012 at 9:35 PM, Sergei Gorelkin sergei_gorel...@mail.ru wrote: So, this is basically a first step of locking Windows RTL to use utf-8 by default No, it will not use UTF-8 by default because that would break compatibility. It will use the system encoding by default and you can use SetMultiByteConversionCodePage to change it to use UTF-8. And this is not about just about Windows, but all platforms of the Ansi RTL. Just that most other platforms are already using APIs which can handle Unicode so they don't need changes. SetMultiByteConversionCodePage is not specific to the Windows RTL. and reducing chances it ever will call 'W' API without conversions? This is a very strange argument. You cannot oppose something by arguing that then it will be successful and people will not want to implement your way. There are no such barriers in a volunteer led project. If someone wants the UnicodeString RTL ... he can write it. I am not against another RTL existing which will use UnicodeString or which will use 1 different string in each platform or 1 different string for each weather condition. But I just don't want to use it. I want to use the Ansi RTL + SetMultiByteConversionCodePage to make it UTF-8 capable, so that's what I am writing. So do you think that the Ansi RTL should not exist? Or you just think it should exist, but in disgrace, using obsolete APIs and with APIs which don't work properly to get people to give up on it? It has already been clearly stated that the Ansi RTL will not be deleted, and this RTL will not follow Delphi Unicode (because that would break compatibility). So if we will have an Ansi RTL, then people that use it intensively should be allowed to improve it. Make it respect SetMultiByteConversionCodePage fully and make it work reliably, make it support UTF-8 and use newer APIs when possible. Like my proposed patch does for improving the Unicode support of TStringList.LoadFromFile / SaveToFile. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On Tue, 7 Feb 2012, Felipe Monteiro de Carvalho wrote: On Mon, Feb 6, 2012 at 9:35 PM, Sergei Gorelkin sergei_gorel...@mail.ru wrote: So, this is basically a first step of locking Windows RTL to use utf-8 by default No, it will not use UTF-8 by default because that would break compatibility. It will use the system encoding by default and you can use SetMultiByteConversionCodePage to change it to use UTF-8. And this is not about just about Windows, but all platforms of the Ansi RTL. Just that most other platforms are already using APIs which can handle Unicode so they don't need changes. SetMultiByteConversionCodePage is not specific to the Windows RTL. and reducing chances it ever will call 'W' API without conversions? This is a very strange argument. You cannot oppose something by arguing that then it will be successful and people will not want to implement your way. There are no such barriers in a volunteer led project. If someone wants the UnicodeString RTL ... he can write it. I am not against another RTL existing which will use UnicodeString or which will use 1 different string in each platform or 1 different string for each weather condition. But I just don't want to use it. I want to use the Ansi RTL + SetMultiByteConversionCodePage to make it UTF-8 capable, so that's what I am writing. Let me intercede here: The plans are already laid out. The ANSI RTL will be exactly that: ANSI; No unicode or UTF-8 hacks will be added to it. The planned unicode RTL will be unicode, and by corollary will support UTF-8. So any patches to utf8-enable the Ansi RTL will not be accepted. You'll have to wait for the unicode RTL or start work on it yourself. If you want, I can send you the details in private, and you can decide for yourself what to do. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
Felipe Monteiro de Carvalho schrieb: Hello, SysUtils for Windows utilizes only A Windows APIs, while it could use W APIs in Windows NT. The attached patch starts correcting improving the situation. Advantages of the patch: * Allows for unicode file names in TStringList.LoadFromFile if you install paswstrings as the unicode manager. Disadvantages of the patch: * None that I can imagine. IMO a more radical solution is desireable, WRT Win9x. Did anybody test already, how FPC/Lazarus apps behave on such a system, which does not support themes etc., and does not even support Unicode without system updates? I'd split the Win32 target into WinNT (W) and Win9x (A), so that the users can decide whether to support Win9x at all. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
Michael Van Canneyt schrieb: As you know, we are very keen on backwards compatibility. ACK. Are you sure that if a AnsiString filename which contains codepage-specific characters is used to open a file, it will still open the same file after this patch is applied ? Win32 filesystems store long filenames in Unicode (UTF-16), I'd not expect problems in addressing files using UnicodeStrings. In particular, does the opening of a DOS-style filename (Program~1\blah) still work as it used to ? I'm not sure, but aren't DOS filenames restricted to the OEM codepage? There exists no direct correspondence between long filenames and their 8.3 names, which may have any number after ~, depending on the contents of the directory. Such names never should occur hard-coded in an application. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
In our previous episode, Felipe Monteiro de Carvalho said: No, it will not use UTF-8 by default because that would break compatibility. It will use the system encoding by default and you can use SetMultiByteConversionCodePage to change it to use UTF-8. Note that this might sound useful now ansistring without codepage is still the default string, but if the default string type changes, this is not really useful. IOW it is a short term hack with a long time support burden IMHO. That being said, I do think we will need to start migrating to the W versions in time. But first a proper decision must be made about the default string type, and such things shouldn't be slipped by the back door. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
In our previous episode, Hans-Peter Diettrich said: IMO a more radical solution is desireable, WRT Win9x. Did anybody test already, how FPC/Lazarus apps behave on such a system, which does not support themes etc., and does not even support Unicode without system updates? I'd split the Win32 target into WinNT (W) and Win9x (A), so that the users can decide whether to support Win9x at all. That depends on decisions still to be made. If we also support 1-byte RTL, it will still be on the level of winNT. But I do think that a win9x vs winnt split is unavoidable in time. Specially since otherwise one gets in the current situation that win9x is occasionally fixed for a release, but in reality constantly broken in between. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 07.02.2012 18:01, Felipe Monteiro de Carvalho wrote: Stay tunned for the next chapters of the Unicode wars =) Here we agree... ;) *fetches popcorn* Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
Hello, SysUtils for Windows utilizes only A Windows APIs, while it could use W APIs in Windows NT. The attached patch starts correcting improving the situation. Advantages of the patch: * Allows for unicode file names in TStringList.LoadFromFile if you install paswstrings as the unicode manager. Disadvantages of the patch: * None that I can imagine. Waiting for comments. -- Felipe Monteiro de Carvalho unicodesysutils.diff Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On Mon, 6 Feb 2012, Felipe Monteiro de Carvalho wrote: Hello, SysUtils for Windows utilizes only A Windows APIs, while it could use W APIs in Windows NT. The attached patch starts correcting improving the situation. Advantages of the patch: * Allows for unicode file names in TStringList.LoadFromFile if you install paswstrings as the unicode manager. Disadvantages of the patch: * None that I can imagine. Waiting for comments. As you know, we are very keen on backwards compatibility. Are you sure that if a AnsiString filename which contains codepage-specific characters is used to open a file, it will still open the same file after this patch is applied ? In particular, does the opening of a DOS-style filename (Program~1\blah) still work as it used to ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
As you know, we are very keen on backwards compatibility Ummm, I'll need to investigate that. But if it seams risky we could always add and (DefaultSystemCodePage = CP_UTF8) to the if, which would disable it for legacy code and enable it only for Unicode applications. If you use SetMultiByteConversionCodePage then you are clearly saying you desire Unicode support. On Mon, Feb 6, 2012 at 7:39 PM, Thaddy tha...@thaddy.com wrote: IMO This should not be done that way (at all): MS does it by respecting the PE flag for unicode and expects strings accordingly: If the PE says it's unicode, a default string should be unicode, (so apiW) if the header says ansi the default should be apiA. The Microsoft way is not the same as the Free Pascal way. We are not required to immitate them when implementing our routines. The Microsoft way has nasty side effects: 1 makes it impossible to support Unicode and support Windows 9x at the same time, but I doubt that Free Pascal wants to drop Windows 9x support (even if it is obsolete). 2 Breaks the interface because the string type changed -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 19:54, Felipe Monteiro de Carvalho wrote: The Microsoft way is not the same as the Free Pascal way. We are not required to immitate them when implementing our routines. The Microsoft way has nasty side effects: 1 makes it impossible to support Unicode and support Windows 9x at the same time, but I doubt that Free Pascal wants to drop Windows 9x support (even if it is obsolete). 2 Breaks the interface because the string type changed No, this is not true, not at all, to the contrary, that's what the PE flag is for: If you want to compile for any windows version, choose ansi mode and the OS respects and expects that. If you want a unicode default (i.e. win2000 and higher) choose unicode mode. The library should be totally opaque when the programmer decides what he wants. What you are doing is making changes in the generated code that shoukld be resolved at compile time. This can be resolved at link time, but I expect it should be resolved at compile time. That's why I agree with you that changes are necessary. (Although the PE flag is a linker instruction) What we are required to do is respect the OS we compile for. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 19:54, Felipe Monteiro de Carvalho wrote: The Microsoft way is not the same as the Free Pascal way. We are not required to immitate them when implementing our routines. The Microsoft way has nasty side effects: 1 makes it impossible to support Unicode and support Windows 9x at the same time, but I doubt that Free Pascal wants to drop Windows 9x support (even if it is obsolete). 2 Breaks the interface because the string type changed No, this is not true, not at all, to the contrary, that's what the PE flag is for: If you want to compile for any windows version, choose ansi mode and the OS respects and expects that. If you want a unicode default (i.e. win2000 and higher) choose unicode mode. The library should be totally opaque when the programmer decides what he wants. What you are doing is making changes in the generated code that shoukld be resolved at compile time. This can be resolved at link time, but I expect it should be resolved at compile time. That's why I agree with you that changes are necessary. (Although the PE flag is a linker instruction) What we are required to do is respect the OS we compile for. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 06.02.2012 20:20, Thaddy wrote: On 6-2-2012 19:54, Felipe Monteiro de Carvalho wrote: The Microsoft way is not the same as the Free Pascal way. We are not required to immitate them when implementing our routines. The Microsoft way has nasty side effects: 1 makes it impossible to support Unicode and support Windows 9x at the same time, but I doubt that Free Pascal wants to drop Windows 9x support (even if it is obsolete). 2 Breaks the interface because the string type changed No, this is not true, not at all, to the contrary, that's what the PE flag is for: If you want to compile for any windows version, choose ansi mode and the OS respects and expects that. If you want a unicode default (i.e. win2000 and higher) choose unicode mode. The library should be totally opaque when the programmer decides what he wants. What you are doing is making changes in the generated code that shoukld be resolved at compile time. This can be resolved at link time, but I expect it should be resolved at compile time. That's why I agree with you that changes are necessary. (Although the PE flag is a linker instruction) What we are required to do is respect the OS we compile for. There is no option to set anything unicode related in the linker according to this page: http://msdn.microsoft.com/en-us/library/y0zzbyt4.aspx So what are you talking about? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
In our previous episode, Felipe Monteiro de Carvalho said: 1 makes it impossible to support Unicode and support Windows 9x at the same time, but I doubt that Free Pascal wants to drop Windows 9x support (even if it is obsolete). Afaik we already have. Recent versions require patches for win9x ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
06.02.2012 20:39, Felipe Monteiro de Carvalho пишет: Hello, SysUtils for Windows utilizes only A Windows APIs, while it could use W APIs in Windows NT. The attached patch starts correcting improving the situation. Advantages of the patch: * Allows for unicode file names in TStringList.LoadFromFile if you install paswstrings as the unicode manager. Disadvantages of the patch: * None that I can imagine. Waiting for comments. So, this is basically a first step of locking Windows RTL to use utf-8 by default and reducing chances it ever will call 'W' API without conversions? Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 21:35, Sergei Gorelkin wrote: 06.02.2012 20:39, Felipe Monteiro de Carvalho пишет: So, this is basically a first step of locking Windows RTL to use utf-8 by default and reducing chances it ever will call 'W' API without conversions? That is another point that worries me too. Windows NT + are not native UTF8 but UTF16. That's why my suggestion to make the default string type fully opaque per platform requirements. That can be done on the compiler level with little effort in rtl/fcl. (For KOL it took weeks, not months) smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
Of course, KOL is a framework, not a compiler. I merely want to state it can be done in a proper way. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
06.02.2012 23:45, Marco van de Voort пишет: In our previous episode, Felipe Monteiro de Carvalho said: 1 makes it impossible to support Unicode and support Windows 9x at the same time, but I doubt that Free Pascal wants to drop Windows 9x support (even if it is obsolete). Afaik we already have. Recent versions require patches for win9x Just in case: I have written a small unicows.dll loader unit (under 10KBytes source code, in contrast with 300KByte Rob Kennedy's one) that can be used as a 'last goodbye' for win9x, allowing to switch most APIs to 'W'. The only issue is that it needs to be executed as early as possible, ideally before system.pp initialization. This probably can be solved by redefining the entry point passed to linker, or by placing its code into yet another sysinit unit, which is selected for win9x. If this is interesting I can provide more details. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 22:14, Sergei Gorelkin wrote: under 10KBytes Any decent code under 10k is interesting smile smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
