> > > However, OpenSSL's license is incompatible with the GPL,
> hence any GPL'd
> > > applications that wish to use an OpenSSL-backed CryptoAPI
> implementation
> > > would be unable to do so.
> >
> > I'm not so sure about this. Question: is it possible to
> write GPL'd
> > software under Windows that links into, say, USER32.DLL?
> Answer: yes,
> > because USER32.DLL is considered part of the operating system.
> > It might be that cryptoapi's dll is also considered part of
> the win32
> > operating system api, thus allowing even gpl'd apps to dynamically
> > link to it without violating the gpl.
>
> Sure, but I think it's a fine line to walk.. The Microsoft-provided
> ADVAPI32.DLL is considered part of the OS, but the API itself is not.
> If you were to create a replacement ADVAPI32.DLL for use
> under Windows,
> I don't think it would be legal for GPL apps to link with it; but hey,
> IANAL, as they say. In any case, the line is even blurrier with wine,
> since wine itself isn't part of the OS -- so someone wanting to port a
> GPL'd windows app [for the sake of argument let's pretend that some
> exist ;-)] to Linux using winelib might have issues.
This issue has been discussed before (see mailing list archive).
I think that the general consensus is that the GPL certainly could be
interpreted (and indeed likely to be interpreted by a court) as not
covering such cases as above, especially since the GPL obviously do not
cover a GPL:ed application on Windows it would be ridiculous to make it
legal distribute Wine and a Windows binary but not Winelib and make it
illegal to do that with a Linux binary that dynamicly links to whatever
version of Winelib installed of the system. The fact that a version of
Winelib might exist that links to a GPL:ed library is a ridiculous
ground for an court case. You might as well argue that distribution
of any Windows binary is illegal since somebody might run it on a
illegal (pirated) version of Windows.
Beside the GPL doesn't cover use, only distribution, so if the user
would install a Winelib that uses a GPL library that would be
completely legal as far as that user would be concern despite the
fact that he has a non-GPL:ed application that uses Winelib.
That would effectively close any "have no legal uses" argument
eventhough that argument is ridiculous regardless of this since
even though no non-GPL:ed Wine implementation of CryptoAPI currently
exists the application might be used with limited functionality until
such time or that matter use the real ADVAPI.DLL from
a legally bought copy of Windows instead.
Beside I don't think any copyright holder of a GPL library would
dare sue the Wine project or any user of Winelib, even disregarding
their non existing chances of success, because of PR reason.
However Alexandre has clearly expressed that he doesn't want Wine
to be a legal test bed, if not primarily for the legal issues, so
because he doesn't want an unsuspecting company using Winelib be
"cruficed" on Slashdot or wherever for alleged GPL violation. :-)
While I, in some meaning, agree, I do not believe that we should
refrain from doing so because of fear of what might never be.
Obviously we should turn off the use of any GPL:ed library by default.
Anyway, unless or until Alexandre changes his mind, I think that
you should submit all general code that needn't use a specific
library and distribute that rest as a patch. Preferable so
that Winelib could dynamically load it so it could be
distributed seperately in binary form as well.
eric pouech wrote:
>
> for some (unexplained yet reasons), my libc implementation for memset
> reads the content of the buffer it's supposed to fill
> since the buffer passed in dsound init has only write access (it's
> needed
> for OSS in order to know it's a buffer for recording or playing), some
> seg fault occurs
>
> I wrote it the easiest way (I don't think it's worth adding a configure
> test for that)
>
> so I replaced the memset by a hand made equivalent
>
> (btw: libc 2.1.3 as shipped by Mandrake 7.2 ; bug has been submitted to
> Mdk QA site, still waiting for some acknowledgement)
ok.. got some feedback from the mandrake folks regarding this bug
I'm looking for someone with a Mandrake 8.1 installed to test if the bug
has been fixed in later release of mdk... any volunteer ?
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
Recently had a problem with specmaker not generating prototypes. Traced it
down to a problem in function_grep.pl.
If the following lines are in a .h file, no prototypes after them are
recognized. Removing the lines from the .h file allows the prototype to be
generated:
#define IShellIcon_METHODS \
ICOM_METHOD3(HRESULT, GetIconOf, \
LPCITEMIDLIST,pidl, UINT,flags, LPINT,lpIconIndex)
I suspect that the preprocessor elimination did not expect multiline
condition. I don't know perl so I cann't fix it.
Thanks,
Guy Albertelli <<galberte(a)neo.lrun.com>>
I was fooling arround with wine installation and now have a big problem,
Firstly I had problems with size of my disk so I downloaded a RPM file from
wine.dataparty.no
glibc2-RPM (requirements):
Latest stripped build: wine-cvs-stripped-090401-1.i386.rpm
Latest unstripped build: wine-cvs-unstripped-090401-1.i386.rpm
these two, then I could not make it running so I downloaded a gzip and make a
new fresh one and it comes upto this level :
Compiling regapi...
gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall
-mpreferred-stack-boundary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/X11R6/include
-o regapi.o regapi.c
ld -r regapi.o -o regapi.tmp.o
strip --strip-unneeded regapi.tmp.o
LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH"
../../tools/winebuild/winebuild -fPIC -L../../dlls -sym regapi.tmp.o -o
regapi.spec.c -spec ./regapi.spec
gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall
-mpreferred-stack-boundary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/X11R6/include
-o regapi.spec.o regapi.spec.c
gcc -shared -Wl,-Bsymbolic regapi.spec.o regapi.o -o regapi.so
-L../../library -lwine -lncurses -lm -lutil -ldl
rm -f regapi && ln -s ../../wine regapi
Preparing to install default Wine registry entries...
Installing default Wine registry entries...
wine client error:0x80685e8: version mismatch 48/51.
Your wineserver binary was not upgraded correctly,
or you have an older one somewhere in your PATH.
Or maybe the wrong wineserver is still running?
Registry install failed.
so u see it is some client/server error and now I cant go further plz help me
out !
regards
PS : Read too much of RTFM :P
Pavel Machek suggested GPLing the netwarefs tools, or no one would be able to use the source. Jeff replied, "I will cross mount the manos
server to the FTP server this evening. This server has all of the source code for the entire TRG archive. I'll put all of it up this evening. It
will be mounted off of /archive in the ftp home area. It also contains all of the Microsoft source code for all of our W2K file systems work.
If it's helpful to anyone, they are welcome to it." Pavel reiterated, "Putting it off /archive is not enough, it does not make it GPLed. Those
tools that are usefull should be marked with GPL so it is *legal* to use them. (You might also consider creating sourceforge.net project
and putting your stuff there ;-)" Jeff replied, "It's all GPL, even the MS code. Sourcefroge is a great idea. I'll look into it."
found here:
http://kt.zork.net/kernel-traffic/kt20010903_131.html#4
There are a group of functions in the kernel that appear to be broken in that they don't follow the Windows API specification. The general convention for these functions is as follows:
The function is called with a pointer to a buffer and the size of the buffer, and returns the number of characters copied to the buffer, excluding the null terminator, unless the buffer is too small when the total size in characters of the buffer needed (with a null terminator) is returned. If the buffer is too small, the string is not copied at all.
Several functions that I have spotted don't implement this correctly - particularly ones in files/directory.c. eg GetSystemDirectory.
They count the Null Terminator. A typical symptom of this is that an installation program attempts to call LoadLibrary on "C:\\WINDOWS\\SYSTEM", because it's appended eg "OLE32.DLL" after the null character. This is one of the problems when installing the Microsoft installer, for example.
While looking for other functions that might do the same thing, I came across this:
/***********************************************************************
* GetCurrentDirectoryW (KERNEL32.@)
*/
UINT WINAPI GetCurrentDirectoryW( UINT buflen, LPWSTR buf )
{
LPSTR xpath = HeapAlloc( GetProcessHeap(), 0, buflen+1 );
UINT ret = GetCurrentDirectoryA( buflen, xpath );
if (ret < buflen) ret = MultiByteToWideChar( CP_ACP, 0, xpath, -1, buf, buflen ) - 1;
HeapFree( GetProcessHeap(), 0, xpath );
return ret;
}
But HeapAlloc takes a number of bytes, whereas buflen is in (two-byte) characters. ie a small buffer would appear to crash this code. (right?)
While I have succesfully patched these bugs on my machine, I'm not sure that going through and looking for every function that may be broken in some similar way and changing them one-by-one is a good way to proceed. These bugs all have to do with returning strings - it would probably be better to attempt to have functions that 'copy out an ANSI string' or 'copy out a UNICODE string' according to this API. Without meaning to be critical, the problem appears to be that the same functionality has been written many times throughout the code, and so multiple and different bugs have crept in.
However, I'm quite new to using wine, and so would like the advice and opinions of those more experienced. My questions:
1) Is there a design reason why a single common function for string copying is not used? Maybe something to do with separate libraries, some of which may be replaced by native windows DLLs? Maybe someone more knowledgeable than myself could direct me as to the best place to put the helper function implementations.
2) Would writing these string helper functions and changing (most) string-returning functions to use them be worthwhile (or indeed even welcome)?
3) Is there a move to using UNICODE internally in the kernel that means that this would be best combined with some other effort? Certainly if this were an eventual design goal then using helper functions would make that job a little easier.
Comments?
Justin SB
Hi,
I was going to start implementing the Cypto API (in advapi32.dll) over the
next few weeks. As of yet these functions are no more than stubs. However,
I am finding increased use of this API as more applications becomed
networkable and relying more heavily on internet connections.
I was hoping to implement these functions by using the OpenSSL library
(if/when available). This library seems to have similar capabilities.
One of my concerns is about legal issues. What special concerns should I
note about cryptographic software? Are there any special copyright issues I
should be aware of?
Another question is about design. M$ seems to split the cryptographic
software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.).
Should I do this as well so that, applications can use the native dlls if
necessary or should I simply implement it entirely though advapi32.dll which
and avoid the need to create several new (and very small) dlls under wine?
Because most of the code is already in another library (OpenSSL) creating
extra dlls seems abit unnecessary.
- Travis
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Hi,
Some time ago I realized that the command line handling in Wine did
not work properly when arguments with spaces or double-quotes are
involved. For instance I would start a Wine application like this:
main "a b" c
and it would tell me something like this:
GetCommandLine=[./main a b c]
Or I would call CreateProcess(... "main \"a b\" c" ...) and main
would get:
main -> argc=4
0 [./main]
1 [a]
2 [b]
3 [c]
So I investigated this and found that
* double-quotes, '"', have the same meaning in win32 as in unix
(tested on Win95 & Win2000)
* backslash, '\', work as on unix, especially wrt double-quotes
* single-quotes, ''', have no special meaning
So CreateProcess(... "main \"a b\" c" ...) should give me:
GetCommandLine=[./main "a b" c]
main -> argc=3
0 [./main]
1 [a b]
2 [c]
I searched for places where we convert command lines to argv lists
and reciprocally and modified them to work as on windows. With this
patch things should be correct, whether you call a Wine application from
Unix, from another Wine application via CreateProcess, or if you call a
Unix application from Wine. There's just one little bit in the msvcrt
code which I treated in a separate patch (p20010902-cmdline2.diff).
In the process I wrote a few test applications:
* hello
regular hello world unix app
* main
A Wine console application which dumps its argc/argv and then calls
GetCommandLine, ...
You can also call it with a '-i' parameter to test
CommandLineToArgvW, except that _getws is not implemented in Wine so
you can only do that on windows
* winmain
A Wine Gui application which dumps lpCmdLine and then calls
__getmainargs, CommandLineToArgvW(GetCommandLineW), ...
* createp
Which reads a command line from stdin and calls CreateProcess with it
* spawnv
Reads a list of arguments from stdin and calls spawnv with it
(spawn* don't handle ' ' and '"', see p20010902-cmdline3.diff)
* spawn
Same but the command is fixed
I know that there has been discussions about the command line
handling before and that some applications do very weird things. Please
test this patch and let me know how it goes.
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
If it stinks, it's chemistry. If it moves, it's biology.
If it does not work, It's computer science.
