Re: shell shorcuts

[Subhobroto Sinha]

One day thus spake Martin Fuchs:

>I am working on the ReactOS Explorer, which uses Wine's shell32 implementation.
>We already have made many bugfixes and estensions to the shell link and other
>shell32 code. One of those extensions is the implementation of control panel in
>shell namespace

I am already aware of that (thanks to Steve), and I would appreciate if someone could 
send me the changes/patches to shell32 by the ReactOS team (even if the source does 
not compile) so I can have a look..
Perhaps you can send me a zip of the ReactOS shell32 directory (keep the makefiles and 
.defs out - send just the real source :) ) ? That will be nice

>Well, I think it's because it has been defined wrong. I am currently using this
>definition:

>#define SCF_UNICODE 0x80(instead of 0x1000)

>This is at least compatible to links of WIN95 (ANSI strings) and WIN XP (UTF16 
>strings).
>I did not yet test any other operating system versions. With this corrected
>defintion and a few more extensions Stream_LoadString() works pretty well
>on ReactOS.

Hmm..., I KNOW 'SCF_UNICODE' is NOT 0x1000 in the first place, but why do you say it's 
0x80 ?

Going by the copyrights, Marcus Meissner and Juergen Schmied did the initial job, and 
perhaps one of them put this value.
I don't know about Juergen, but I have tremendous faith in Marcus (I use SuSE you see 
;) ), and there MUST have been some reason why 'SCF_UNICODE' got the value 0x1000, 
although it seems to be wrong !

Hence, please consolidate your assigning it 0x80 with some examples/hexedits so that I 
can answer when I get grilled ;)

However, I think that we should ALL handle strings as Unicode internally, and convert 
to ANSI when required, and NOT the other way round.
Hence, we will be compatible with Win98/ME/2K/XP, as that's what M$ does...
If you see my code carefully, you will notice that EVERYTHING is handled as Unicode 
internally.

The flag 'SCF_UNICODE' is used to test the bit mask and determine if the .lnk is 
serialized in Unicode or not...
I am pretty sure that Windows >95 handle EVERYTHING in Unicode, and thus a wrong value 
of 'SCF_UNICODE' will ONLY mess up Win95 .lnk files !

If you can consolidate your defining 'SCF_UNICODE' as 0x80, I will ONLY be too happy 
to incorporate that, else those still using Win95 (?) may suffer, as Win95 handles 
strings as ANSI and not Unicode...

Will send Alexandre my patch within the next few days as no one has objected to it 
being messy, so take the last chance ;)

BTW Martin, great work with ROSExplorer, keep at it, and one day WINE will have a 
complete Desktop with shell namespaces !

Regards

Subhobroto Sinha 

Of games and shorcuts [was -> Re:More Games Tested]

[Subhobroto Sinha]

Hello all,

I had completed the patch for IPersistFile::Load() and associated functions. In the 
last patch which I had submitted for review here, Mike McCormack had pointed out an 
incorrect assumption that I had made about all locales being DBCS. Thanks to him, many 
of you will not suffer ;)

Now that I fixed that last (?) weeny, I had sent it to Mike for a review. However, it 
seems he's a bit down now, and after waiting for about a week for his reply, I thought 
maybe I should ask you guys to nitpick ;)

I really send this in because I went through Mike Kost's post 'More Games Tested', and 
I saw  lots of 'err:menubuilder' and 'err:menubuilder:WinMain failed to build menu 
item for C:\windows\Start Menu\Programs\...\ShortcutName.lnk' messages in his 
report.
Hopefully, this patch should solve it ...

If I get any bug reports, I will be happy to fill them out,else this one's going to 
Alexandre (with a few cosmetic changes of course !)

Regards

Subhobroto Sinha 

--- shelllink.c.original2003-10-22 17:56:30.0 +0530
+++ shelllink.c 2003-12-24 22:29:59.0 +0530
@@ -401,9 +400,49 @@
return S_OK;
 }
 
+static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )
+{
+DWORD count=0;
+USHORT len;
+LPWSTR str=NULL;
+HRESULT r;
+/*
+From Win98 upwards everything internally is maintained as unicode.(Atleast M$ 
says so)
+Also, the value of SCF_UNICODE does NOT seem to be 0x1000, hence the bitwise '&' 
returns a false, even if it's unicode.
+Until the correct value is found, we assume it Unicode. This should not break 
ANYTHING >Win95 for shortcuts
+Anybody differing mail to .
+*/
+TRACE("%p\n", stm);
+
+r = IStream_Read(stm, &len, sizeof(len), &count);
+if(FAILED(r)||(count != sizeof(len))) return E_FAIL;
 
+len *= sizeof(WCHAR);
+
+TRACE("reading %d\n", len);
+str = HeapAlloc(GetProcessHeap(), 0, len+sizeof(WCHAR));
+if(!str) return E_OUTOFMEMORY;
+
+count = 0;
+r = IStream_Read(stm, str, len, &count);
+if( FAILED(r)||( count!=len) )
+{
+HeapFree( GetProcessHeap(), 0, str );
+return E_FAIL;
+}
+
+str[count/2]=0;
+*pstr = str;
+TRACE("read %s\n", debugstr_w(str));
+return S_OK;
+}
+
+#if 0
 static HRESULT Stream_LoadString( IStream* stm, BOOL unicode, LPWSTR *pstr )
 {
+   /*This is the original function now redirected to the above till we find out 
correct 'SCF_UNICODE'.
+   Now it's assumed that the data's unicode. (This assumption failes iff the OS was 
<=Win95, so I don't think it will hurt anybody)*/
+
 DWORD count;
 USHORT len;
 LPVOID temp;
@@ -454,6 +493,7 @@
 
 return S_OK;
 }
+#endif
 
 static HRESULT Stream_LoadLocation( IStream* stm )
 {
@@ -503,9 +543,10 @@
 IStream* stm)
 {
 LINK_HEADER hdr;
-ULONGdwBytesRead;
+ULONGdwBytesRead=0;
 BOOL unicode;
 WCHARsTemp[MAX_PATH];
+WCHAR wszTemp[MAX_PATH]={0};
 HRESULT  r;
 
 _ICOM_THIS_From_IPersistStream(IShellLinkImpl, iface);
@@ -515,7 +556,6 @@
 if( !stm )
  return STG_E_INVALIDPOINTER;
 
-dwBytesRead = 0;
 r = IStream_Read(stm, &hdr, sizeof(hdr), &dwBytesRead);
 if( FAILED( r ) )
 return r;
@@ -533,6 +573,12 @@
 if( FAILED( r ) )
 return r;
 }
+
+SHGetPathFromIDListW(This->pPidl,wszTemp);
+This->sPath = HeapAlloc( GetProcessHeap(), 0, lstrlenW(wszTemp)*sizeof(WCHAR) );
+lstrcpyW(This->sPath,wszTemp);
+TRACE("%s\n",debugstr_w(This->sPath));
+
 This->wHotKey = hdr.wHotKey;
 This->iIcoNdx = hdr.nIcon;
 FileTimeToSystemTime (&hdr.Time1, &This->time1);


diff.zip
Description: Zip compressed data

Re: Re: wchar_t on GNU and Win32 - two worlds apart !

[Subhobroto Sinha]

The program runs on Windows just fine because Windows Unicode function expects wchar_t 
to be 2 bytes (unlike GNU's) which is what it gets..

So the program runs on wine correctly too...

But I want the app to be a native ELF using GLibc's own Internal functions...

I have assumed that the user may not have WINE

Regards

On Sun, 28 Dec 2003 Dan Kegel wrote :
>Dan Kegel wrote:
>>I'm way out of touch with Wine these days, but here's
>
>[ meant to say "my two bits"... obviously my mind is wandering... ]
>
>>1. If you want to get something useful done, switch to C.  Mixing
>>g++ and Winelib seems to be a bit tricky, and you might end up
>>spending all your time on that instead of solving the problem you
>>originally wanted to solve.
>>
>>2. If you insist on using C++:
>>if the problem resists analysis, perhaps you could use Valgrind
>>to help track down the problem.
>
>3. Compile with MS Visual C++.  I run MSVC++ 4.0 on Wine just fine,
>and I bet even newer versions will run the commandline versions
>of the compilers ok on wine.
>
>#3 really is the best option, since then your app will
>run fine both on Windows and on Wine...
>
>- Dan
>
>

Re: Re: wchar_t on GNU and Win32 - two worlds apart !

[Subhobroto Sinha]

No, actually I really don't want to use WineLib (then I can use COM to resolve the 
shortcut anyway!)

I just want a method where I can use GLibc's Unicode functions on Win32 serialized 
data which treats wchar_t as 2 bytes long..

On Sun, 28 Dec 2003 Dimitrie O. Paun wrote :
>On December 27, 2003 01:11 pm, Subhobroto Sinha wrote:
> > But as I am using pure C++, I have to use GLibc's library functions which
> > expects wchar_t to be 4 bytes long and NOT 2 bytes.
>
>Herein lies your problem. Mixing the two is not pretty, and I think
>it should be avoided to maintain sanity. Just use our msvcrt for the
>Unicode functions, it uses 2-byte wchar_t, so you can mix that freely
>with the other Win32 functions.
>
>--
>Dimi.
>

wchar_t on GNU and Win32 - two worlds apart !

[Subhobroto Sinha]

Hello

The main problem is that wchar_t is 4 bytes on GNU, but 2 bytes on Windows !

Though Windows typedefs WCHAR as a wchar_t, but there a wchar_t is an "unsigned 
short", whereas on GNU it's "unsigned long"

So WCHAR serialized data from Windows will get messed if we use native GNU data types 
(because then the program will read 4 bytes instead where it should have read 2 
bytes!).

Now you don't have to worry about WINE, as WINE defines the data type just as Windows 
and hence there's no problem with WINE's internationalization functions (MultiByte.. 
or WideChar... etc)

But as I am using pure C++, I have to use GLibc's library functions which expects 
wchar_t to be 4 bytes long and NOT 2 bytes.

So as a workaround I defined these two functions to convert from wchar_t and WCHAR to 
keep GNU's wcstombs() happy:

inline void Convert_wchar_t_ToWCHAR(const wchar_t* wszIn,WCHAR* wszOut)
{
  if(wszIn) while(*wszOut++=*wszIn++);
  else *wszOut=0;
}

and

inline void ConvertWCHARTo_wchar_t(const WCHAR* wszIn,wchar_t* wszOut)
{
  if(wszIn) while(*wszOut++=*wszIn++);
  else *wszOut=0;
}

As you can see, all the above two does is JUST copy the arrays from one data type to 
another.

As we are reading the data from a .lnk (and thus the wchar_t strings are 2 byte arrays 
in the file..), there's no harm done, as by copying the 2 byte array into a 4 byte 
array, there is no loss of information.

But, unfortunately, (but NOT always..), the function wcstombs fails.

I have attached the binary and source alongwith a .lnk which demonstrates this problem.

You just need to pass the .lnk filename to the binary on the command line, and it will 
spit out a few details at out about the .lnk

If you test the .lnk (DAEMON_TOOLS.LNK), you will see that the program crashes in the 
function:

unsigned int WineWorksShortcutResolver::UnicodeToANSI(const WCHAR* 
wszInUnicode,unsigned int uiLen,char* szOutANSI)

at the GLibc function:

wcstombs(..)

The most confusing thing is that this does not happen in case of any other .lnk that I 
have (which are not many..) !

Any suggestions ?

Regards

Subhobroto Sinha

Problem.zip
Description: Zip compressed data

Yeah - our RichEDit needs some work

[Subhobroto Sinha]

;)

Actually, I noticed this many times before(text not displaying at all in a RichEdit 
control..)

I am one of those (un)fortunate enough to not have a real Windows, and often download 
Win32 freeware to see how WINE's doing from time to time...

IMHO, one of the best tests are Steve Gibson's (www.grc.com) freeware tools - this guy 
writes in pure ASM. and thus we can be sure that his code will be the least messy 
(lesser MS stuff..)

However, if you try his 'Wizmo' or 'DCOMObulator', you will see that the RichEdit 
textareas as blank !

Unfortunately, the guy does not release his source (though I have reason to believe he 
would to anyone asking for it..)

You may try them out in WINE guys, they are REALLY small (small code - that's a rarity 
on Windows nowdays.. people nowdays do not even use Win32 SDK,leave alone ASM)

Guess we really need some work at RichEdits...

I posted this mainly because it seems Zimler Attila wants to help - so there you are 
(^-^)

BTW: CodeWeavers have good support for RichEdit controls, but why does not WINE ?

Regards

Subhobroto Sinha

Of wchar_t and WCHAR and incompatibilities....

[Subhobroto Sinha]

As most of you might be aware, I and Robert are progressing with a Start Menu.

All the functionality is there now (except menu icons, and shell namespaces..).

However, I had to write a .lnk parser for it and till date, I made it compatible ONLY 
with UTF-8 and thus did not require to use glibc's Unicode functions.

Today, I was getting dirty with a full blown Unicode implementation and I noticed that 
GNU defines a wchar_t as an (unsigned long) - it's 4 bytes long, wheras a WCHAR (which 
is a typedefed wchar_t) is an (unsigned short) on Windows !

As a result, Unicode strings on Windows are unsigned long arrays and thus I had to 
convert them into glibc's own wchar_t format using a hack like this:

void ConvertWCHARTo_wchar_t(const WCHAR* wszIn,wchar_t* wszOut)
{
if(wszIn) while(*wszOut++=*wszIn++);
}

and vice versa for the opposite conversion.

Believe me, it works, but not always... (any body interested in debugging with the 
source, please ask me for it..)

Any sugestions as to handle the situation please?
I need to use GLibc's Unicode functions and NOT WINE's implmentation of Mutibyte...(), 
because I want to keep the .lnk parser in pure C++

Regards

Subhobroto Sinha

Re: I made a wish, wrote a letter to Santa...

[Subhobroto Sinha]

Actually Shachar, 

I was thinking along these lines:

(1) Programs in WINE are making direct calls to internal functions (which are not 
really Win32, but made by us using which we can use te Win32 functions as wrappers...) 
and that's just possible because C functions are globally callable (the only thing you 
really need to keep the compiler happy is the function prototype)

And that's a bad thing, because while developing tools we should really forget that we 
are coding fo WINE, and just write using Win32 SDK APIs...

Encapsulating internal WINE functions as private, and exposing them using the correct 
APIs would be better engineering...

Just to force lazy people like us to write protable code (you see, calling internal 
WINE functions are a lot easier than calling the corresponding wrappers..

(2) A few things like DirectX and COM are so very closely tied with C++ objects that 
implementing them in C seems an overkill to me. But after knowing they are done, I 
have nothing against that 

(3) C++ is VERY reusable. WINE has a lot of potential for reusablity , but by doing C 
where it was not needed, we are unnecessarily having to spend time finding out pieces 
here and there in the huge code structure.

WINE is recieving more interest than ever, and we can only encourage people to join us 
by giving something they too can reuse, and people who really work for WINE are those 
types who start writing their own code if they find that tracing down a function and 
it's references will take more time.

For example, whatever I have gone through (which is VERY little BTW..), I still feel 
that implementing many tools like winemenubuilder or winefile would have been better 
in C++

Infact, I intent to do some experimentation after Xmas (I am having  my semester exams 
now, so ..)

Hope what I said reaches you all ;)

Season's greetings

Subhobroto


On Thu, 11 Dec 2003 Shachar Shemesh wrote :

>I'm sorry, it has been YEARS since I wrote anything OLE related (my very first 
>Windows program was an OLE server, hand coded, that did a shell extension. That was 
>my only interaction with OLE). As such, I will not presume to decide whether that 
>statement is correct or not.

Re: Re: I made a wish, wrote a letter to Santa...

[Subhobroto Sinha]

To be honest, if you follow my previous posts, I DID write some C++.

Albeit, that was not reallt necessary ... ;)

Anyways, I will submit a pure C and a C++ version of future patches, sch that both 
work under the current WINE.

After that, it will be upto Sir Julliard...

Season's Greetings

Subhobroto Sinha

>On Wed, 10 Dec 2003 Sir Marcus Meissner wrote thus:

>Read what Alexandre wrote. To paraphrase:
>
>"Feel free to write it in C++ and submit it when you are done."
>
>Ciao, Marcus
>

Sorry for spamming the list..

[Subhobroto Sinha]

Hello

I am really sorry for making multiple posts - I got the Rediffmail mailer's 
verification after 20 minutes (normally Yahoo!'s mailservers notify almost 
instantaneously..), but before I could realize it, my 4 messages had already been 
mailed out of the queue...

This was the first time I was using an Indian mail server, and well as it turns out, 
it was slower than a USA server ?!

Regards

Subhobroto Sinha

I made a wish, wrote a letter to Santa...

[Subhobroto Sinha]

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he 
would let his elves use C++ in WINE.

(Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', 
and you can make your wishes at 'wine-devel[at]winehq.com'..)

You see, Santa was always so good - he answered people's prayers and got together his 
obedient elves to run Win32 on Non-Windows platforms!

However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, 
DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain 
C, and thus developments in those areas were soon in limbo.
But that could be solved using yet another language called C++ - if only Santa would 
let it be.

Oh please Santa ! Let us adultrate WINE with C++, please.

It's not that we will rewrite everything in C++ once we get the green signal - things 
like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but 
what about MFC, COM, OLE ?

Not that I expect to compile native MFC source using WineLib, but at least we can 
write the runtimes so that native MFC apps can atleast run under WINE ?

DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM 
and already our implementations have structure object pointers running wild, whereas 
encapsulation would have done away with it !

As a simple explanation, we might take our 'This' hack wheras C++ would let have us 
use it as 'this' without even us worrying about it !
Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX 
source as I do not have a graphics base at all ..) where initializing a few member 
variables from a constructor would have done away with some redundancy.

Most of the time we are passing around multilevel pointers when a simple reference 
would have done:

For example a call like

Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT 
Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )']

can be made to a simple

Stream_LoadString(sString);

using C++ if we had the prototype rewritten to 'static HRESULT 
Stream_LoadString(LPWSTR& pstr )' and makin

I made a wish, wrote a letter to Santa...

[Subhobroto Sinha]

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he 
would let his elves use C++ in WINE.

(Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', 
and you can make your wishes at 'wine-devel[at]winehq.com'..)

You see, Santa was always so good - he answered people's prayers and got together his 
obedient elves to run Win32 on Non-Windows platforms!

However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, 
DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain 
C, and thus developments in those areas were soon in limbo.
But that could be solved using yet another language called C++ - if only Santa would 
let it be.

Oh please Santa ! Let us adultrate WINE with C++, please.

It's not that we will rewrite everything in C++ once we get the green signal - things 
like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but 
what about MFC, COM, OLE ?

Not that I expect to compile native MFC source using WineLib, but at least we can 
write the runtimes so that native MFC apps can atleast run under WINE ?

DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM 
and already our implementations have structure object pointers running wild, whereas 
encapsulation would have done away with it !

As a simple explanation, we might take our 'This' hack wheras C++ would let have us 
use it as 'this' without even us worrying about it !
Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX 
source as I do not have a graphics base at all ..) where initializing a few member 
variables from a constructor would have done away with some redundancy.

Most of the time we are passing around multilevel pointers when a simple reference 
would have done:

For example a call like

Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT 
Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )']

can be made to a simple

Stream_LoadString(sString);

using C++ if we had the prototype rewritten to 'static HRESULT 
Stream_LoadString(LPWSTR& pstr )' and making it a member function of IStream (and thus 
the 'IStream* stm' and 'BOOL unicode' would be member variables..)

We have code like that all over the place whenever COM etc comes into play and "That's 
Not A Good Thing(TM)" !

Please give us the green card - alternately, a new test branch may also be created 
just to see if C++ would work.All C++ based modfications would goto that tree.
If that test branch works and delivers, it maybe merged into the main WINE tree, 
otherwise if it fails 

I made a wish, wrote a letter to Santa...

[Subhobroto Sinha]

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he 
would let his elves use C++ in WINE.

(Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', 
and you can make your wishes at 'wine-devel[at]winehq.com'..)

You see, Santa was always so good - he answered people's prayers and got together his 
obedient elves to run Win32 on Non-Windows platforms!

However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, 
DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain 
C, and thus developments in those areas were soon in limbo.
But that could be solved using yet another language called C++ - if only Santa would 
let it be.

Oh please Santa ! Let us adultrate WINE with C++, please.

It's not that we will rewrite everything in C++ once we get the green signal - things 
like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but 
what about M

I made a wish, wrote a letter to Santa...

[Subhobroto Sinha]

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he 
would let his elves use C++ in WINE.

(Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', 
and you can make your wishes at 'wine-devel[at]winehq.com'..)

You see, Santa was always so good - he answered people's prayers and got together his 
obedient elves to run Win32 on Non-Windows platforms!

However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, 
DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain 
C, and thus developments in those areas were soon in limbo.
But that could be solved using yet another language called C++ - if only Santa would 
let it be.

Oh please Santa ! Let us adultrate WINE with C++, please.

It's not that we will rewrite everything in C++ once we get the green signal - things 
like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but 
what about MFC, COM, OLE ?

Not that I expect to compile native MFC source using WineLib, but at least we can 
write the runtimes so that native MFC apps can atleast run under WINE ?

DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM 
and already our implementations have structure object pointers running wild, whereas 
encapsulation would have done away with it !

As a simple explanation, we might take our 'This' hack wheras C++ would let have us 
use it as 'this' without even us worrying about it !
Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX 
source as I do not have a graphics base at all ..) where initializing a few member 
variables from a constructor would have done away with some redundancy.

Most of the time we are passing around multilevel pointers when a simple reference 
would have done:

For example a call like

Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT 
Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )']

can be made to a simple

Stream_LoadString(sString);

using C++ if we had the prototype rewritten to 'static HRESULT 
Stream_LoadString(LPWSTR& pstr )' and makin

I made a wish, wrote a letter to Santa...

[Subhobroto Sinha]

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he 
would let his elves use C++ in WINE.

(Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', 
and you can make your wishes at 'wine-devel[at]winehq.com'..)

You see, Santa was always so good - he answered people's prayers and got together his 
obedient elves to run Win32 on Non-Windows platforms!

However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, 
DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain 
C, and thus developments in those areas were soon in limbo.
But that could be solved using yet another language called C++ - if only Santa would 
let it be.

Oh please Santa ! Let us adultrate WINE with C++, please.

It's not that we will rewrite everything in C++ once we get the green signal - things 
like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but 
what about MFC, COM, OLE ?

Not that I expect to compile native MFC source using WineLib, but at least we can 
write the runtimes so that native MFC apps can atleast run under WINE ?

DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM 
and already our implementations have structure object pointers running wild, whereas 
encapsulation would have done away with it !

As a simple explanation, we might take our 'This' hack wheras C++ would let have us 
use it as 'this' without even us worrying about it !
Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX 
source as I do not have a graphics base at all ..) where initializing a few member 
variables from a constructor would have done away with some redundancy.

Most of the time we are passing around multilevel pointers when a simple reference 
would have done:

For example a call like

Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT 
Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )']

can be made to a simple

Stream_LoadString(sString);

using C++ if we had the prototype rewritten to 'static HRESULT 
Stream_LoadString(LPWSTR& pstr )' and making it a member function of IStream (and thus 
the 'IStream* stm' and 'BOOL unicode' would be member variables..)

We have code like that all over the place whenever COM etc comes into play and "That's 
Not A Good Thing(TM)" !

Please give us the green card - alternately, a new test branch may also be created 
just to see if C++ would work.All C++ based modfications would goto that tree.
If that test branch works and delivers, it maybe merged into the main WINE tree, 
otherwise if it fails to deliver just remove it after a stipulated period !

If WINE stuck to C only because some platforms do not support C++, then will Win32 
apps run on such OS at all ? Things like SPARC do not need MS Apps at all (though 
SPARC has C++..)

For a expert discussion on C++ please see http://www.research.att.com/~bs/blast.html
Microsoft themselves use C++ :


Microsoft: Literally everything at Microsoft is built using various flavors of Visual 
C++ - mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-( and some 
products like Windows XP use more recent builds of the compiler. The list would 
include major products like:

Windows XP 
Windows NT (NT4 and 2000) 
Windows 9x (95, 98, 

[OT] HOWTO use unnamed KRun objects ?

[Subhobroto Sinha]

I thought a simple 'KRun(KURL("SomeBinaryFilename"))'
should work, but it doesn't ?

(I get ld telling me that there was an undefined
reference to KRun::KRun(const KURL&...) !)

Please tell me/redirect me(just make sure that the
reference is working!) to an example where I can use
KRun in such a manner, because KDE3API really does not
come with sample code to help the uninitiated.

I really just want to open files with their bound apps
through my program, for ex: A KRun("Page.html") should
open the 'Page.html' in Konqueror

Thanks for letting me bug you ;)

Regards

Subhobroto Sinha

__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: Is secdrv.sys a "Protection Mechanisim"

[Subhobroto Sinha]

Greets

Jonathan has started discussion on a VERY delicate
topic.

IMHO, 'secdrv.sys' is a vital DLL for a Win32 copy
protection system called SafeDisc by Macrovision.
I am not really into this kinda stuff, but I know a
friend who does, he's Kamal Shankar  and I had an IRC meet with him.

As far as I came to know from a discussion with him,
it's really more than just something to detect SoftICE
or TRW2000 - it can detect disk cloning, compromise of
the SafeDisc protection system, function redirection
through Detours or even Ordinal overrides!
It also appears that 'secdrv.sys' is encrypted (like
other parts of Safeisc) using TEAK and I do not think
that implementing it in WINE will be possible at all !

So really you can neither 'stub out' nor 're-write'
nor 'clone' the functions in there, and may you never
try it (at least publicly!)

Also, the SafeDisc system is a copyrighted work and
Macrovision OR atleast TransGaming should be contacted
before we get our hands dirty.

Obviously, if we get the green signal, we will have to
use Hardware Debuggers anyways, and the costs invloved
is .

Also,as SafeDisc is more of a 'copy protection' than
'execution locking', once we know how the decryption
keys are generated, we even do NOT need to implement
SafeDisc! We can easily unwrap the exe!

I refrain from discussing the methods (if I know at
all) which can get us at that direction, but let me
tell you - the code to do this already has been
released in assembly (hint, hint !)

I sincerely hope that we divert our efforts to other
causes than play Win32 games, Transgaming has a
specialization towards that field, though it's really
unfortunate that thet refrain from sharing that
knowledge.

Regards

Subhobroto Sinha

P.S: "The war has come to an end, but the movie was
very disappointing"


__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

WineHQ: Corrected PATCH to fix IPersistFile::Load() and associated functions.

[Subhobroto Sinha]

Hello all

I corrected my last patch after replacing everything
C++ into C.

This patch has been inlined as well as attached as a
ZIP file, so suit yourself.

All reports regaring this patch is to be sent to
 with a proper subject
prefixed by "IPersistFile patch" in the subject
header.

This patch fixes:

(1) Stream_LoadString: Conflict of unicode strings
being taken as LPSTR and AGAIN being converted to
Unicode due to wrong value of SCF_UNICODE .(I have
preprocessed out the original code. This should remain
so until SCF_UNICODE value is corrected) 
(2) Stream_LoadLocation: Previously the GetPath()
failed. It works great now.

Now IPersistFile::Load() should work as intended. Try
out McCormack's 'winemenubuilder' or my WineLib
'linkresolve' (NOT my C++ version)

If the diff is not proper, etc, please alert me at the
mentioned address

PS: As I am not a member of 'wine-patches',can the
moderator be kind enough... :=)
I really want these functions to get fixed. That's
all.

Regards

Subhobroto Sinha

__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

Patch.tar.gz
Description: Patch.tar.gz
--- wine-20031016/dlls/shell32/shelllink.c  2003-10-29 21:07:43.0 +0530
+++ Shikayat/dlls/shell32/shelllink.c   2003-10-29 20:39:56.0 +0530
@@ -401,9 +401,49 @@
return S_OK;
 }
 
+static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )
+{
+DWORD count=0;
+USHORT len;
+LPWSTR str=NULL;
+HRESULT r;
+/*
+From Win98 upwards everything internally is maintained as unicode.(Atleast M$ 
says so)
+Also, the value of SCF_UNICODE does NOT seem to be 0x1000, hence the bitwise '&' 
returns a false.
+Until the correct value is found, we assume it Unicode. This should not break 
ANYTHING >Win95 for shortcuts
+Anybody differing mail to .
+*/
+TRACE("%p\n", stm);
+
+r = IStream_Read(stm, &len, sizeof(len), &count);
+if(FAILED(r)||(count != sizeof(len))) return E_FAIL;
 
+len *= sizeof(WCHAR);
+
+TRACE("reading %d\n", len);
+str = HeapAlloc(GetProcessHeap(), 0, len+sizeof(WCHAR));
+if(!str) return E_OUTOFMEMORY;
+
+count = 0;
+r = IStream_Read(stm, str, len, &count);
+if( FAILED(r)||( count!=len) )
+{
+HeapFree( GetProcessHeap(), 0, str );
+return E_FAIL;
+}
+
+str[count/2]=0;
+*pstr = str;
+TRACE("read %s\n", debugstr_w(str));
+return S_OK;
+}
+
+#if 0
 static HRESULT Stream_LoadString( IStream* stm, BOOL unicode, LPWSTR *pstr )
 {
+   /*This is the original function now redirected to the above till we find out 
correct 'SCF_UNICODE'.
+   Now it's assumed that the data's unicode. (This assumption failes iff the OS was 
<=Win95, so I don't think it will hurt anybody)*/
+
 DWORD count;
 USHORT len;
 LPVOID temp;
@@ -454,6 +494,7 @@
 
 return S_OK;
 }
+#endif
 
 static HRESULT Stream_LoadLocation( IStream* stm )
 {
@@ -503,9 +544,10 @@
 IStream* stm)
 {
 LINK_HEADER hdr;
-ULONGdwBytesRead;
+ULONGdwBytesRead=0;
 BOOL unicode;
 WCHARsTemp[MAX_PATH];
+char szTemp[MAX_PATH]={0};
 HRESULT  r;
 
 _ICOM_THIS_From_IPersistStream(IShellLinkImpl, iface);
@@ -515,7 +557,6 @@
 if( !stm )
  return STG_E_INVALIDPOINTER;
 
-dwBytesRead = 0;
 r = IStream_Read(stm, &hdr, sizeof(hdr), &dwBytesRead);
 if( FAILED( r ) )
 return r;
@@ -533,6 +574,13 @@
 if( FAILED( r ) )
 return r;
 }
+
+SHGetPathFromIDListA(This->pPidl,szTemp);
+This->sPath=HeapAlloc( GetProcessHeap(), 0,(strlen(szTemp)+1)*sizeof(WCHAR));
+dwBytesRead=(strlen(szTemp)+1);/*Just to hold the length of the string*/
+MultiByteToWideChar(CP_ACP,0,szTemp,dwBytesRead,This->sPath,dwBytesRead);
+TRACE("%s\n",debugstr_w(This->sPath));
+
 This->wHotKey = hdr.wHotKey;
 This->iIcoNdx = hdr.nIcon;
 FileTimeToSystemTime (&hdr.Time1, &This->time1);

WineHQ: PATCH to fix IPersistFile::Load() and associated functions

[Subhobroto Sinha]

Hello all

I finally produced the "official patch" after
verifying that everything is OK.

This patch has been inlined as well as attached as a
ZIP file, so suit yourself.

All reports regaring this patch is to be sent to
 with a proper subject
prefixed by "IPersistFile patch" in the subject
header.
Just don't simply hit the 'Reply' button !

This patch fixes:

(1) Stream_LoadString: Conflict of unicode strings
being taken as LPSTR and AGAIN being converted to
Unicode due to wrong value of SCF_UNICODE .(I have
really NOT changed the original code, but redirected
this call to a fixed function which I named
wineStream_LoadString. This should remain so until
SCF_UNICODE value is corrected) 
(2) Stream_LoadLocation: Previously the GetPath()
failed. It works great now.

For the uninitiated, here's what has to be done:

Please make sure that you have the 20031016 source
(latest tarball)

(1)Copy this .diff to the root folder of the Wine
source
(2)Run 'patch' on this diff file
(3)It should patch "dlls/shell32/shelllink.c". Change
to that directory
(4)Type 'make' to rebuild 'shell32.dll.so'
(5)'su' out and overwrite/symlink the current
'shell32.dll.so' over the installed one

Now IPersistFile::Load() should work as intended. Try
out McCormack's 'winemenubuilder' or my WineLib
'linkresolve' (NOT my C++ version)

If the diff is not proper, etc, please alert me at the
mentioned address

PS: As I am not a member of 'wine-patches',can the
moderator be kind enough... :=)
I really want these functions to get fixed. That's
all.

Regards

Subhobroto Sinha

__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

patch.zip
Description: patch.zip
--- dlls/shell32/shelllink.c.original   2003-10-22 17:56:31.0 +0530
+++ dlls/shell32/shelllink.c2003-10-26 16:30:57.0 +0530
@@ -401,9 +401,49 @@
return S_OK;
 }
 
+static HRESULT wineStream_LoadString( IStream* stm, LPWSTR *pstr )
+{
+DWORD count=0;
+USHORT len;
+LPWSTR str=NULL;
+HRESULT r;
+/*
+From Win98 upwards unicode==TRUE.(Atleast for shortcuts..)
+However, the value of SCF_UNICODE does NOT seem to be 0x1000.
+Until then, we assume it true.
+Anybody differing mail to .
+*/
+TRACE("%p\n", stm);
+
+r = IStream_Read(stm, &len, sizeof(len), &count);
+if(FAILED(r)||(count != sizeof(len))) return E_FAIL;
+
+len *= sizeof(WCHAR);
+
+TRACE("reading %d\n", len);
+str = HeapAlloc(GetProcessHeap(), 0, len+sizeof(WCHAR));
+if(!str) return E_OUTOFMEMORY;
+
+count = 0;
+r = IStream_Read(stm, str, len, &count);
+if( FAILED(r)||( count!=len) )
+{
+HeapFree( GetProcessHeap(), 0, str );
+return E_FAIL;
+}
+
+str[count/2]=0;
+*pstr = str;
+TRACE("read %s\n", debugstr_w(str));
+return S_OK;
+}
 
 static HRESULT Stream_LoadString( IStream* stm, BOOL unicode, LPWSTR *pstr )
 {
+/*This is the original function short circuited to the above till we find out correct 
'SCF_UNICODE'.
+Now it's assumed that the data's unicode. (This assumption failes iff the OS was 
<=Win95*/
+return (wineStream_LoadString(stm,pstr));
+#if 0
 DWORD count;
 USHORT len;
 LPVOID temp;
@@ -453,6 +493,7 @@
 *pstr = str;
 
 return S_OK;
+#endif
 }
 
 static HRESULT Stream_LoadLocation( IStream* stm )
@@ -533,6 +574,14 @@
 if( FAILED( r ) )
 return r;
 }
+
//
+char szTemp[MAX_PATH]={0};
+SHGetPathFromIDListA(This->pPidl,szTemp);
+This->sPath=HeapAlloc( GetProcessHeap(), 0,(strlen(szTemp)+1)*sizeof(WCHAR));
+
MultiByteToWideChar(CP_ACP,0,szTemp,(strlen(szTemp)+1),This->sPath,(strlen(szTemp)+1));
+//TRACE("%s\n",szTemp);
+
//
+
 This->wHotKey = hdr.wHotKey;
 This->iIcoNdx = hdr.nIcon;
 FileTimeToSystemTime (&hdr.Time1, &This->time1);

WineHQ: PATCH to fix IPersistFile::Load() and associated functions

[Subhobroto Sinha]

Hi.

I finally produced the "official patch" after
verifying that everything is OK.
Thanks to Dimi for putting up a temporary diff for me
meanwhile ;)

This patch has been inlined as well as attached as a
ZIP file, so suit yourself.

All reports regaring this patch is to be sent to
 with a proper subject
prefixed by "IPersistFile patch" in the subject
header.

For the uninitiated, here's what has to be done:

Please make sure that you have the 20031016 source
(latest tarball)

(1)Copy this .diff to dlls/shell32/
(2)Run 'patch' on this diff file
(3)It should patch "shelllink.c"
(4)Type 'make' to rebuild 'shell32.dll.so'
(5)'su' out and overwrite/symlink the current
'shell32.dll.so' over the installed one

Now IPersistFile::Load() should work as intended. Try
out McCormack's 'winemenubuilder' or my WineLib
'linkresolve' (NOT my C++ version)

If the diff is not proper, etc, please alert me at the
mentioned address

BTW: If I should have submitted at 'wine-patches'
rather at 'wine-devel', please let me know :=)
I really want this BUG fixed you know ;-)

Regards

Subhobroto Sinha


--- shelllink.c.original2003-10-22 17:56:31.0
+0530
+++ shelllink.c 2003-10-24 13:09:59.0 +0530
@@ -18,7 +18,7 @@
  * Foundation, Inc., 59 Temple Place, Suite 330,
Boston, MA  02111-1307  USA
  *
  * NOTES
- *   Nearly complete informations about the binary
formats 
+ *   Nearly complete informations about the binary
formats
  *   of .lnk files avaiable at http://www.wotsit.org
  *
  */
@@ -401,9 +401,49 @@
return S_OK;
 }
 
+static HRESULT wineStream_LoadString( IStream* stm,
LPWSTR *pstr )
+{
+DWORD count=0;
+USHORT len;
+LPWSTR str=NULL;
+HRESULT r;
+/*
+From Win98 upwards unicode==TRUE.(Atleast for
shortcuts..)
+However, the value of SCF_UNICODE does NOT seem
to be 0x1000.
+Until then, we assume it true.
+Anybody differing mail to .
+*/
+TRACE("%p\n", stm);
+
+r = IStream_Read(stm, &len, sizeof(len), &count);
+if(FAILED(r)||(count != sizeof(len))) return
E_FAIL;
+
+len *= sizeof(WCHAR);
+
+TRACE("reading %d\n", len);
+str = HeapAlloc(GetProcessHeap(), 0,
len+sizeof(WCHAR));
+if(!str) return E_OUTOFMEMORY;
+
+count = 0;
+r = IStream_Read(stm, str, len, &count);
+if( FAILED(r)||( count!=len) )
+{
+HeapFree( GetProcessHeap(), 0, str );
+return E_FAIL;
+}
+
+TRACE("read %s\n", debugstr_w(str));
+str[count/2]=0;
+*pstr = str;
+return S_OK;
+}
 
 static HRESULT Stream_LoadString( IStream* stm, BOOL
unicode, LPWSTR *pstr )
 {
+/*This is the original function short circuited to
the above till we find out correct 'SCF_UNICODE'.
+Now it's assumed that the data's unicode. (This
assumption failes iff the OS was <=Win95*/
+return (wineStream_LoadString(stm,pstr));
+#if 0
 DWORD count;
 USHORT len;
 LPVOID temp;
@@ -453,6 +493,7 @@
 *pstr = str;
 
 return S_OK;
+#endif
 }
 
 static HRESULT Stream_LoadLocation( IStream* stm )
@@ -533,6 +574,27 @@
 if( FAILED( r ) )
 return r;
 }
+/*Fill in the target path. This marked portion
will be rewritten once GetPathFromIDList() is
completed*/
+//LPITEMIDLIST
pidltemp=_dbg_ILGetNext(This->pPidl);
+LPITEMIDLIST pidltemp=ILGetNext(This->pPidl);
+char
szPasha[128][MAX_PATH]={{0},{0}},szTemp[MAX_PATH]={0};
+int i=0,j=1;
+do
+{
+   
_ILSimpleGetText(pidltemp,szPasha[i++],MAX_PATH);
+pidltemp=ILGetNext(pidltemp);
+}while(pidltemp->mkid.cb);
+strcpy(szTemp,szPasha[0]);
+for(;jsPath=HeapAlloc( GetProcessHeap(),
0,(strlen(szTemp)+1)*sizeof(WCHAR));
+   
MultiByteToWideChar(CP_ACP,0,szTemp,(strlen(szTemp)+1),This->sPath,(strlen(szTemp)+1));
+TRACE("%s\n",szTemp);
+/*End marking*/
 This->wHotKey = hdr.wHotKey;
 This->iIcoNdx = hdr.nIcon;
 FileTimeToSystemTime (&hdr.Time1, &This->time1);



__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

patch.zip
Description: patch.zip

FIX for BUG in IPersistFile::Load() since Wine-20030618 !

[Subhobroto Sinha]

First I had to learn COM (Aaaahhg!!!...), then learnt
to translate COM to C++.
(Learning COM was the hardest part since I had to hire
some computer time from our local computer parlour
which has Windows boxes alongwith VC++, and then I had
to juggle to and forth from there to home after my
college hours..)

Then created my OWN Win32 app (from scratch..) to read
and resolve .lnk files.
Then translated the Win32 app to PURE C++, so that it
ran under GNU/Linux...

Then applied the knowledge to Wine, and got the
IPersistFile::Load() working...

So the attachment "ShellLink.zip" contains the
modified "dll/shell32/shellink.c" file which fixes the
BUG in Load().

Sorry, but it's the WHOLE file.
I have changed the original file so much that to
submit a proper patch I need an unmodified
"shelllink.c" (I do have a backup, but where was that
?)

So in the meantime befor I submit a proper patch,
check it out.

Instructions: (duh!)


Just create a backup of the existing "shelllink.c" and
then copy this attached "shelllink.c" to
"dlls/shell32/shelllink.c"
 Type 'make'; copy the new "shell32.dll.so" to your
installed wine folder (you should be root), and run
any program which resolves shortcuts.

You can try the "linkresolve.exe.so" (from my previous
posts. See the archvies..) or WineMenuBuilder.

Hoping to recive reports soon (send them at
[subhobrotosinha at yahoo.com]

Regards

Subhobroto Sinha

__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

shelllink.zip
Description: shelllink.zip

Of Start Menu, Shortcuts and broken functions...

[Subhobroto Sinha]

ving the messages for the above APIs from Wine
while running my shortcut resolving code (found in the
archives) OR McCormack's 'winemenubuilder'.

I hope to get a suitable response to this post. PLEASE
correct me if I have gone wrong anywhere! Thanks :=)

Also, I will be VERY happy to recieve
pseudocode/algorithm for the mentioned APIs specially
Stream_LoadString() and IPersistStream_fnLoad() as I
am having a hard time understanding a few lines in the
code. And could someone send me the layout of .lnk
files ?

Please keep up the good work.
Regards

Subhobroto Sinha

__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

BUG in IPersistFile::Load() since Wine-20030618 !

[Subhobroto Sinha]

This is a followup of my earlied post.

Recap: I was porting my program which resolved Windows
shortcut files (.lnk) using WineLib (Please note that
this program runs flawlessly on Windows).
It used to work fine till I updated my Wine source
from 20030408 to 20030813.

I posted this report here and Dimitrie suggested that
I do a CVS Regression test to locate the error...

Now, I really could NOT do a CVS regression test as I
lack the bandwidth (you know, a 28KBps modem ..), but
I started afresh with the Wine-20030408 source tree
and "patch-compile-tested" to version 20030618.
Then I found out that from this release onwards
IPersistFile::Load() had become BROKEN !

Hence I have reason to believe that ANY code which
modified/touched directly/indirectly
IPersistFile::Load() and made it's way into
Wine-20030618.diff.gz is AT FAULT ;)
And that code needs to be FIXED.

So ALL Wine releases prior to 20030618 can sucessfully
run my program(or for that matter, ANY program that
calls IPersistFile::Load()) , and ANY Wine release
after 20030618 will fail ANY application that calls
IPersistFile::Load() !

Just to show that not just my program is at fault, you
can also try running Mike McCormack's WineMenuBuilder
which also resolves Windows shortcuts...

Until IPersistFile::Load() got broken, on running my
program this is the ONLY message I used to get :
"fixme:shell:IShellLinkA_fnResolve
(0x4039da98)->(hwnd=(nil) flags=3)"

The attached file "WineTraceLog.zip" contains the
pertinent extract of the trace log when I run my
program, please go through it to see what really is
happenning.
(While going through this extract you can see that the
shortcut has been resolves sucessfully, but yet
IPersistFile::Load() returns a failure ??)

I hope this gets fixed allright ;)
Please let me know if I can help in any way (EXCEPT
learning COM!)...

Regards

Subhobroto Sinha

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

WineTraceLog.zip
Description: WineTraceLog.zip