Update: well I did a raw DEVOUT for loop test, and it was a only about 10%
slower. The 2 or 3 times slower claim was in the ap we use itself, where we
have another test which does almost the same thing, and it is about 2 or 3
times slower... not sure what really is responsible, only thing I know
Hi Viktor,
It turns out that my tests of doing the devout calls to the screen in Win9x
with the unicows solution is about 2 or 3 times slower than non-unicode
compiled .EXEs on the same machine. And this is with Przemek's SET CURSOR
OFF trick as well for Win9x machines...
So this simple test and
Hi Mindaugas,
> I see no problem for Win 3.x and Win32s, we still have customers with Win9x.
> Many of the projects are contained in the only .exe file, so requirement of
> extra .dll is not nice. One more thing is that my libraries are non-UNICODE,
> but I do not see a big reason to do rewrite
Hi,
I see no problem for Win 3.x and Win32s, we still have customers with
Win9x. Many of the projects are contained in the only .exe file, so
requirement of extra .dll is not nice. One more thing is that my
libraries are non-UNICODE, but I do not see a big reason to do rewrite a
working piec
Thank you!
On Thu, Apr 29, 2010 at 4:00 PM, Viktor Szakáts wrote:
>
> You are missing the component 'unicows' library.
>
> Download it from above link, unpack and copy to one
> of the existing lib dirs, or point to it using -L
> (libpath option).
>
> Viktor
>
_
> [ Forgot to mention here that this requires recent
> Harbour version, 2.0.0 release won't work. Maybe
> worth to note that ]
>
> I have not found that in the INSTALL doc...
> G:\ver10\harbour-dev>grep -in unicows INSTALL
> 630: UNICOWS solution to support Win9x/
Ooopsies... I meant to say "error" in the line below.
On Thu, Apr 29, 2010 at 3:48 PM, smu johnson wrote:
> I have found that produces an hour when I compile harbour devs with
> win-make myself (which is my only choice, as 2.0.0 is the last stable
> bundled released, afaik).
>
>
--
smu johnson
Hi again,
On Thu, Apr 29, 2010 at 3:21 PM, Viktor Szakáts wrote:
> The components are also listed in INSTALL.
>
> Quote:
> "in quite simple way. All you need to do is adding
> -lunicows to your hbmk2 make file and bundle
> unicows.dll with your app. Works with all supported
> Harbour compilers. G
Hi,
> It's unlikely we shall ever support Windows 3.x or Win32s,
> and unicows solution works just perfect now to cover Win9x/ME
> host versions, so I can see no hard reason to maintain duplicate
> code paths for both UNICODE and non-UNICODE Windows API
> support.
>
> I have still not yet found a
Hi,
On Thu, Apr 29, 2010 at 5:13 AM, Viktor Szakáts wrote:
> Hi All,
>
> It's unlikely we shall ever support Windows 3.x or Win32s,
> and unicows solution works just perfect now to cover Win9x/ME
> host versions, so I can see no hard reason to maintain duplicate
> code paths for both UNICODE and
Hi Przemek,
> Sorry but I do not understand why do you want to delete
> already working code.
> In longer terms it may cause that we will create problems
> for platform which do not use Unicode forcing Unicode everywhere
> reducing Harbour functionality to current Java or Phyton level.
> For me it
Hi Viktor,
Sorry but I do not understand why do you want to delete
already working code.
In longer terms it may cause that we will create problems
for platform which do not use Unicode forcing Unicode everywhere
reducing Harbour functionality to current Java or Phyton level.
For me it will be end
Hi Przemek,
>> If that simplifies things (which it definitely does), and
>> the majority of developers agree with it, we can drop
>> non-UNICODE mode altogether from Harbour source code.
>> It's unlikely we shall ever support Windows 3.x or Win32s,
>> and unicows solution works just perfect now
On Thu, 29 Apr 2010, Szak�ts Viktor wrote:
Hi,
> If that simplifies things (which it definitely does), and
> the majority of developers agree with it, we can drop
> non-UNICODE mode altogether from Harbour source code.
> It's unlikely we shall ever support Windows 3.x or Win32s,
> and unicows
Hi Chen,
> Viktor,
>
> What is special about "non-unicode Windows" in compare to other
> non windows OS that are currently supported by Harbour? Can't it
All Windows API calls that has to do anything with
strings have two versions: one which deals with
"ANSI" (8-bit) string types and another f
Viktor,
What is special about "non-unicode Windows" in compare to other
non windows OS that are currently supported by Harbour? Can't it
be just considered another type of Os?
(I know that in maintanance therms, it is best to have less variations
as possible)
Chen.
_
Hi All,
If that simplifies things (which it definitely does), and
the majority of developers agree with it, we can drop
non-UNICODE mode altogether from Harbour source code.
It's unlikely we shall ever support Windows 3.x or Win32s,
and unicows solution works just perfect now to cover Win9x/ME
17 matches
Mail list logo
