Yes, I remember Netscape. I used to use the Navigator a long long time ago, too, back when pages had 2-3 images (with a thick blue border around them too) and the appearance of AltaVista was praised with bull sacrifices and ceremonial orgies around the globe...

The thing is, I obviously have no idea what your code looks like, but I still can't see the relation between Unicode and .NET... For me, .NET is something to whip quick "proof of concept" apps, without spending days trying to match pointers and data types in your code, to what Microsoft decided their functions and methods should accept, instead of actually writing code. Unicode, on the other hand, is a saviour (for Greece), and I've been using it in raw C/C++ (console or MFC) as well as C# (obviously) with equal success -- note: I'm NOT a Windows programmer.
In any case... like I said, I don't know how your code has been laid out, but if it's such a big hassle as rewriting your code, screw it. I'm perfectly fine with English anyhow...

Now... version 11.1 eh? Very interesting!!!

Believe me, if I could add Unicode support, I would in the blink of an eye. It's not the code that is the limitation - it's the tool used to build the code that doesn't support it. That means I'm stuck with ANSI, system locales, and the world of code pages.

But it works.

Unfortunately Microsoft made sure there was no direct upgrade path with .NET (although they tried to throw sand in everybody's eyes at the time). Even though .NET does have some nice features (e.g.; Unicode support, lol) you simply can't do this type of stuff in it.

.NET is too big, too buggy, too memory hungry, too slow and too clumsy to build applications with hundreds of thousands of lines of code that rely heavilly on Win32 and need to be as lean and run as fast as possible.

What Microsoft did with Vista to unsuspecting Windows users (breaking backwards compatibility and thus many applications), they did in a much worse scale with .NET to application developers. And by doing so, they betrayed our trust too.

There's a reason that no part of Windows is written in managed code. If .NET is so good, as MS claims it is, why don't they eat their own dog food?

The solution would be to port everything to C++, but then read my previous paragraph regarding what happened to Netscape.

Starting from what you just said, I think I know what language you're using to make Nexus.
Which makes me worried, actually, since Windows 7 is the last version of Windows that supports that 'tool' and that language. Besides, even now, you have serious limitations, like the ability to compile to x64 (since x86-64 didn't even exist when that 'tool' came out), and you shouldn't even be able to use Direct2D for GPU-assisted rendering and effects (I don't know if there are still people making libraries and wrappers for that 'tool').
So, I guess you *will* eventually have to start thinking about the future of all the Winstep applications, and start the -- in my view -- unavoidable task of moving them to C++ or some other modern language.

Anyway, I did try Nexus on a Greek system (Greek GUI, not just Greek NUL) and it does work beautifully. Except, the degree symbol is shown as a question mark on many occasions, and that's something common to this (fully Greek) as well as the other (English UI) systems of mine.

Oh, and another thing. About the translation, I have a problem now that I can see my translation. There are a lot of things that need fixing, since Greek is much more complex a language than English, but I don't know how to find the right items to correct. For instance, "main" in English is just one word, that applies to everything. In Greek, "main" is a lot of different words, depending on the gender and number of the thing(s) it applies to.
So, I don't know how it could be done, but some kind of "markup" would be most welcome, so that I (and other translators) know where the thing that I'm translating comes from.
For instance, when I'm translating "nothing" and "all", I'd like to know that they are the two ends of the slider with the title "How much of each icon should be reflected". Otherwise, my translation will just look ridiculous.
The reverse should also be addressed: now that I've made the wrong translation for those "nothing" and "all" entries, I should have some way of 'navigating' to those specific items and correct them easily. Now, I have no idea how to even find them.

Anyway... cheers!

Oh, don't be. MS already realized how deeply they shot themselves in the foot. Support for the language has already been extended, and it will be again - they have no choice, there are thousands of users - and thousands of high profile business users - still using applications written in classic VB.

Not to mention that Windows 7 will stick around for quite some time now.



That's a 'false' limitation. The 'jump' from 32-bit to 64-bit is not at all like the jump from 16-bit to 32-bit applications. In fact, the only real advantage is that 64 bit applications are able to use more than 2 GB of memory - but then, would anyone really use Nexus if it used THAT much memory? Eheh.

And there are drawbacks for 64 bit applications: they actually consume more RAM. The 32 bit world will happily co-exist with the 64 bit world for a long time to come.



I can use DirectX directly from VB.

There were a lot of things you aren't supposed to be able to do with pure VB - but then VB gives you unfeathered access to the Win32 API, so the world is your oyster. Winstep's WsxService (which takes care of all operations requiring high privileges) is a Windows Service written in VB, and it was generally assumed you could not make a Windows service using VB.



I'm not scared of using other languages. I've used plenty in my life, including writting large applications written in Assembly language (can't get any more hardcore than that, eheh). And I use C++ when I really need to.

That's not the point. The point is that porting the existing applications into another language (and, if I absolutely had to do that, I would use nothing but C++) would be an extremelly time consuming exercise. In the end, all that effort would result in exactly the same that was already there - and which is working fine now - just written in a different language (and probably with lots of new bugs thrown in).



Although I am well aware of this, there isn't much I can do. The only viable solution is for translators to visually identify this problematic spots and report their occurences - then I can, perhaps, use a different word for each of the instances.

Did they? Wow! I thought they had just canceled it, and that was the end of it.



I know. I just want to run native x64 whenever possible. Even just for that. The only thing that's keeping me sane is that even Firefox still has no official x64 build.
(but if Nexus consumes anything more than 100MB I'd kill you (and why does it need 200MB of virtual memory?))



Wow, now that, not only didn't I know, but didn't even imagine. You can actually access the D2D library from VB6?! Damn!


From what I've seen, I never believed you'd be scared of C++, actually. Personally, I'm more scared of programming for Windows than anything C++ or ASM can throw at me (I've written ASM too, for embedded on ARM and 8085). Windows can really intimidate me, though... I'm used to linear code -- and yes, loops and traps and interrupts and functions are still linear code.
If you feel that VB still covers your needs, well, by all means then! I was just referring to the effort you'd need to move from VB to VC++ or whatever flavour.


Uh ow...

Oh, the language itself is dead in the water, but compatibility with VB *applications* persists.



Ever heard of something called 'shared memory', which is shared between all applications and the OS?



The problem with what MS did with classic VB is not one of forcing developers to learn a new language (although that in itself is pretty stupid, as learning the basics of a new programming language is easy, but it takes about 3 years to trully know the ins and outs of that new language and be really confortable and proeficient with it), but what are developers going to do with thousands or millions of lines of code they developed in a language that is now considered obsolete and has no forward upgrade path...

Their businesses depend on that code base, they can't just throw all that out out (and we're talking about millions of dollars in code, time spent, and painfully acquired expertise that MS expected developers to hapilly throw away overnight) and start again from scratch.

So they have no choice but to persist.

Plus, as Bruce McKinney (author of Harcore Visual Basic) once wrote: "Experience has shown that programmers are more disposed to suffer, while limitations are sufferable, than to abandon the languages to which they are accustomed."

In the end, all this is the result of a new 'school of thought' at Microsoft that somehow gained the upper hand against the old school which considered backwards compatibility critical for the sucess of Windows. This resulted in monsters like Vista and .NET, which deliberately broke backwards compatibility, and, as a result, unleashed an untold amount of pain on users and developers alike.

One of the major reasons Windows became so popular is that it remained - and still is, for the most part - compatible with stuff that was written many, many, eons ago. Change must happen, no doubt about it, but it must be progressive, not the result of a clean break with the past.

What a pity I found this thread only yesterday.

I work in technical support of some known localization software vendor. Our tool supports multiple platforms e.g. .NET, Windows 32 (C++), Delphi and my work could gives me some general preview of issues generated by different developing platforms. Dotnet allows on easy (UI) language switching at runtime without using third party solution/components, while this is impossible for C++. Dotnet is really advanced solution, and C# has has all modern features such GC (grabage collector), generics, dynamic variables, LINQ, parallel support, but for this reason it is also very buggy (WPF is awful), especially related to localization. On our support, dotnet generate 90% of issues, while Delphi or C++ don't give problems. So in spite of moder features in NET, I'm not fan of this developing solution. Additional, as Jorge mentioned dotnet isn't compatible with older developing VS solutions from Microsoft. This is simple... Microsoft can implement new functionality, because they don't give a shit about legacy platforms (and users of them!) and don't worry about compatibility issues. So if you would like move your software from C++ to e.g. C# you need rebuild all codes. While if you use old Delhpi 7, you can move your code to Delphi 2010 (with full Unicode support) in easy way, because Embracadero always wants to keep new Delphi backward compatible to the previous. By the other hand, this reason they never implement great improvements.

Just my 2 cents ,
Janusz