Walter wrote:
> Now that I realize that MSLU cannot be installed as part of the OS, you're
> right.

http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx

MSLU appears to consist of a tiny loader, which binds into the application, and the DLL. If the DLL is not found, the loader simply redirects the calls to the OS. Which results in the same as if the loader was not there.

Thus you can call applications which use such a loder "MSLU-aware", and MSLU DLL is then as good as an operaing system update?

Besides, strategy can be destinguished by specifying a version at compile-time. Unicode with MSLU loader, lightweight Unicode (NT only and probably little sense), and lightweight non-Unicode (Windows 9x, good for many fairly language-agnostic applications). BTW, with versions and stuff, time would be coming to think of a better build system. Thanks that the language semantics makes it possible.

-eye

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:btbog7$2dl0$1@digitaldaemon.com...
> Matthew wrote:
> >>With a boolean and some good string conversion routines its simple:
> >>
> >>if(isWinNT())
> >>return SomeFuncW(myString);
> >>else
> >>return SomeFuncA(toAnsi(myString));
> >
> >
> > Your philosophy is right, but the implementation is wrong. There should
be a
> > single function that library code calls. The last thing we'd want is
people
> > testing the boolean themselves. Something along the lines of
> >
> > HANDLE FindFirstFile(
> >   LPCTSTR lpFileName,               // file name
> >   LPWIN32_FIND_DATA lpFindFileData  // data buffer
> > );
> >
> > HANDLE _DLU_FindFirstFileW(wchar_t *searchSpecW, WIN32_FIND_DATAW
*dataW)
>
> I was referring to the way the wrapper functions are implemented. This should be done once for each function, not every time the function is called.

Ok. :)

> Another thing: from what you write it seems to me like you want to create a "better" Win32 API for the programmer.

Absolutely! These issues are a total PITA, and I see no reason why, at this early stage, we cannot decide to step in and fix it for one and all.

And who's to say analogous issues are not to be had on Solatirs, or Mac, or VMS, or whatever?

> I was just referring to
> the way the standard library is implemented. I do not think that such an
> API should be exposed by the standard library, since it will be very
> incomplete.

It's not a trivial job, to be sure.

> Something like a full Unicode Layer for Windows should not
> be integrated into the D core library - this has nothing to do with the
> language itself and should be a separate library if someone wants to do
it.

But people will omit it. The single biggest problem is that most of us
developers are (i) English speakers (whether first language, or just been
forced to be good at it because it's the lingua franca of programming and
popular culture) and (ii) we use NT family boxes.

> Also, a "true" Unicode layer is pretty difficult to implement, as this would include having to wrap the message queue and converting all messages before they are handled by the application (MSLU does this to some degree). For the standard library we won't have that problem, since we do not not access the message queue there.

Excellent point. It is indeed a hard one

> And another thing: the MSLU does still exist, even if it is not required by the core D library. If developers want to have a reasonably complete Unicode layer they may still link to MSLU (if their application type allows it).
>
> I guess my point is that a full Unicode layer is too much work and has nothing to do with the core D language.

Agreed on both point. But the issue still has to be addressed.

The fact that big W was unaware of the stubbed nature of the 9x W functions demonstrates that this is a minefield for all developers, of whatever level of experience.

How about if we start thinking about this a little differently? Maybe rather than concerning ourselves about Windows, we can have a general approach to function declarations. We could have a keyword, dynamic_encoding_function in the following example (a better name would be suggested by an imaginative soul), that would allow us to stipulate that the compiler and/or linker must generate the dispatching code for us. We'd need to tell it what the in and out parameters are, how it makes the determination of which to call, and such like - it's not trivial - but it could be done.


HANDLE FindFirstFileA(char *searchSpec, WIN32_FIND_DATAW data);
HANDLE FindFirstFileA(wchar_t *searchSpec, WIN32_FIND_DATAW data);

dynamic_encoding_function HANDLE FindFirstFile(wchar_t *searchSpec,
WIN32_FIND_DATAW data);
{
  dispatch_switch = std.windows.isWinNT,
  dispatch_case =
    {
        true,                 /* When std.windows.isWinNT is true */
        FindFirstFileA,
        false,             /* Don't do anything on entry */
        false              /* Don't do anything on exit */
    },
  dispatch_default =
    {
        std.windows.opSys.winNT,
        FindFirstFileA,
        true             /* Do something on entry (in this case translate
searchSpec) - we need to work out a general way to decree what is to be done
*/
        true             /* Do something on exit (in this case translate
data) - we need to work out a general way to decree what is to be done */
     },
}


Obviously there's more to it, but I think (hope) you get my drift. This could then be used for more than just character encoding scheme translation, and would not necessarily only be useful for Win32.

It'd need a clear and concise form, but I'll leave it to others to suggest a better one.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btcm5f$s30$1@digitaldaemon.com...
> It has to be linked in, and that has to be in a specific order. If we use
it
> I think the D compiler should handle the onerous linker crud for us automatically.

The more I look at it, the more it looks like the wrong solution for D.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btcm5i$s30$4@digitaldaemon.com...
> Ok, fine. But you have to decide how this is to be handled, whether that
be
> MSLU, or DLU.dll, or DLU.lib, or we don't support 9x execution, or we
leave
> it to the poor developer.

At this point, I don't know what to do. I just don't understand why MS didn't make it an update to the OS, and now they never will as they have officially abandoned 9x.

D relies on the underlying OS for unicode to work, otherwise each executable will have to carry around a huge bloated unicode layer. That might work for a VM based language where customers are used to bloat <g>, but not for a systems language.

I think the right solution is to say that unicode will not work on 9x - just ascii - and provide some kludge for code pages.

Matthew wrote:
>>I guess my point is that a full Unicode layer is too much work and has
>>nothing to do with the core D language.
> 
> 
> Agreed on both point. But the issue still has to be addressed.
> 
> The fact that big W was unaware of the stubbed nature of the 9x W functions
> demonstrates that this is a minefield for all developers, of whatever level
> of experience.

Yes, but changing the way an application interacts with the OS is the wrong way to go, IMHO. I certainly wouldn't want to have such stubs between me and the OS, because I already have an abstraction library. Unnecessary layers mean unnecessary bugs.

So there are really two issues here:

1) How are the Windows calls in the standard library implemented?
2) Is it possible to help people write better, more compatible Unicode application on Windows?

Number 1 is fairly easy to solve by just creating a small number of wrapper functions that are used internally.

Number 2 is a completely different beast. Writing a complete Unicode layer is a HUGE project - not even Microsoft has managed to do it up to now. For example, the Windows Common Controls are not supported in the MSLU, even though they are used in almost all applications.

Also, I think the goal of Number 2 is not inside the scope of a programming language like D. Improving the OS is not the job of the language, it is the job of either the OS creators or library developers.

So I see three options:

a) Just leave it as it is and provide good tool support for easily linking in the MSLU, if the developer wants to do that. The D docs could also feature prominent notice of the MSLU's existence and describe what it does.

b) Create a new wrapper library in D. As I mentioned, this is a lot of work. But there could be some advantages as well: for example, we could write the wrappers in a way so that they take D string objects (of the "new" kind that hides the encoding), instead of raw string data. That would make it even easier for newbies, since then they wouldn't be required to understand which encoding they need for which functions. It could also save some speed on Win9x (if the encoding used in the String objects is not UTF-16), because then we could convert directly to "ANSI" encoding (i.e. the system code page), instead of first converting to UTF16 and then to ANSI.

Solution b will probably always be incomplete and by the time it is reasonably usable many people might have moved on to other OSs.

c) Stick to the MSLU for the time being. And instead of slightly improving the Windows API, invest that work into developing platform independent libraries that work for multiple OSs. If you get right down to it, the goal of this discussion is to have newbies write code that is compatible with all Windows OSs. Wouldn't it be even better if that code also ran on Linux and MacOS? This is also a huge task, but at least there are already a lot of libraries one could utilize (like the Apache Portable Runtime, wxWindows GTK, QT, whatever). The key would be to make these libraries easily accessible, so that newbies use them instead of programming the Windows API directly.

I think if you want to protect people from the hazards of an OS then solution c) is the best way to go. But I wouldn't go that far and make this a part of the D standard library. That would mean that all those platform independent libs HAVE to be implemented for every OS D is ported to - and that could severely hamper the range of systems D is available for.

Better make it a semi-official set of libraries that are "recommended" to use, if available.

Hauke

"Walter" <walter@digitalmars.com> wrote in message news:btcr6g$13ge$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btcm5f$s30$1@digitaldaemon.com...
> > It has to be linked in, and that has to be in a specific order. If we
use
> it
> > I think the D compiler should handle the onerous linker crud for us automatically.
>
> The more I look at it, the more it looks like the wrong solution for D.

I can't conceive of a right solution, but I know that shipping NT-family compiled exes to Win9x and having them fail is going to look back for D, however unfair and unjustified that is.

Matthew wrote:
> "Walter" <walter@digitalmars.com> wrote in message
> news:btcr6g$13ge$1@digitaldaemon.com...
> 
>>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
>>news:btcm5f$s30$1@digitaldaemon.com...
>>
>>>It has to be linked in, and that has to be in a specific order. If we
> 
> use
> 
>>it
>>
>>>I think the D compiler should handle the onerous linker crud for us
>>>automatically.
>>
>>The more I look at it, the more it looks like the wrong solution for D.
> 
> 
> I can't conceive of a right solution, but I know that shipping NT-family
> compiled exes to Win9x and having them fail is going to look back for D,
> however unfair and unjustified that is.
> 
> 

I always use the A api's unless theres no equilavent for a W api that i need to use. In vb all strings (which would be equal to wchar[] or utf16) get converted automatically to char[] by the runtime to call the A api, and then back again. It seems to me that this type of way should be the solution if one wants to generically support both systems (9x an NT). Maybe some kind of flag for NT only? that would use only W api's.

As was stated though, a flag for NTness would probably be best with an: #If NT {use W api;} else {use A api;} might also work.

However (this could possibly get me flamed lol) i also think, because that windows is by far the most popular os, that a specific windows only support library should be built, seperate from possibly another library for unix, linux etc... ;) it cant hurt to wish lol

Another possible solution may be to come up with a new format for defining windows only api. So that the compiler can pick which one to use depending on the OS, dunno...

Hopefully in a year from now i can look back at some of my posts and wonder how i could say such useless things lol i guess leaving something unsaid that may helpful is useless also.

regards
Lewis