"Eric Pouech" <[EMAIL PROTECTED]> wrote:
> but which charset is used when getting the filename (from a directory
> enum for example). The charset of the mount option, the default charset
> of the kernel, or the charset of default locale ?
Look at the following line, borrowed from my /etc/fstab:
On September 24, 2003 06:59 pm, Steven Edwards wrote:
> Or we could just make a new page for WINE porting that contains the
> status of the hardware and software ports such as Sun sparc, the dead
> BeOS and OS/2 ports and now the MS_VC and Cygwin/Mingw ports.
Yes, I'd prefer a separate page, we ha
Alexandre Julliard wrote:
Jakob Eriksson <[EMAIL PROTECTED]> writes:
So where can I get it? I downloaded the latest SDK (or so i think)
from Microsoft, but that didn't help. I am grabbing for straws at this
point.
I don't know. I have them in my comctl32.lib from MSVC 5, maybe they
have
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Well, dependencies are not a problem: I can modify bin2res to output
> the name of the dependencies, and then 'make depend' can include
> them just like it does with the others...
I don't really see how you would do that, especially not to make it
Jakob Eriksson <[EMAIL PROTECTED]> writes:
> So where can I get it? I downloaded the latest SDK (or so i think)
> from Microsoft, but that didn't help. I am grabbing for straws at this
> point.
I don't know. I have them in my comctl32.lib from MSVC 5, maybe they
have been removed in later versio
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> Steven, what about a status for compiling dlls with MinGW/MSVC/etc.?
> It would be nice to have a table like we have for the other stuff
> on WineHQ, detailing the status of this effort...
I would really like to see this. I was thinking we could
On Wed, 24 Sep 2003, Alexandre Julliard wrote:
> Yes that's the right way to do it. The only drawback is that we will
> need to list the dependencies explicitly in the makefile; but we need
> that to really support other resource compilers anyway.
Well, dependencies are not a problem: I can modif
On Wed, 24 Sep 2003, Steven Edwards wrote:
> a week or two. I wont be able to implement the needed interfaces in to
> winmm that will still be up to you but we should have the dll ported
> and working with w32api in a month or two.
Steven, what about a status for compiling dlls with MinGW/MSVC/et
Alexandre Julliard wrote:
Steven Edwards <[EMAIL PROTECTED]> writes:
OK so we know the DPA_Create problems are not just in Mingw. Can we do
something about this now?
You probably need a more recent comctl32.lib. I definitely have these
functions in mine.
So where can I get it? I downl
I will work on this but it may be a while. Once I get my internet
connection back up at home I am going to spend some time working on
getting more of WINE to build with MS_VC and the PSDK. Once that is
done we can do the Mingw work and of course Winmm will be part of this.
I cant give any time tabl
Philipp Wollermann wrote:
Why not fix HeapReAlloc first and see which apps crash? ;-)
it's not a matter of knowing which apps break, but which APIs would break...
Anyway, fixing this seems to be a task I could do, so, if someone could give
me instructions on how to do it ...
cd wine
find . -name
Why not fix HeapReAlloc first and see which apps crash? ;-)
Anyway, fixing this seems to be a task I could do, so, if someone could give
me instructions on how to do it ...
Philipp
On Wednesday 24 September 2003 21:24, Eric Pouech wrote:
> Pavel Roskin wrote:
> > Hello!
> >
> > HeapReAlloc() wou
Pavel Roskin wrote:
Hello!
HeapReAlloc() would crash on Windows 2000 is the original pointer is NULL.
This causes the Andreas Mohr's uninstaller to crash.
there's lot of code which relies on HeapReAlloc would allocate a block
if the block to reallocate is NULL (as realloc does in stdlib).
this is
On Wednesday 24 September 2003 10:55 am, Alexandre Julliard wrote:
> [EMAIL PROTECTED] writes:
> > So, what I'm wondering now is: 1) Should I bother finishing it? OSS is
> > working fine for me again, and if someone else is going to fix the
> > existing ALSA driver, and 2) if the answer to qu
Dmitry Timoshkov wrote:
"Eric Pouech" <[EMAIL PROTECTED]> wrote:
but couldn't this be different from the charset used for mounting the
filesystem ? AFAICS, on VFAT systems, long names are stored in Unicode.
The charset in the mount option let you specify the charset for the
Unicode -> multi-by
On Wed, 24 Sep 2003, Steven Edwards wrote:
> Hello Pavel,
> While you are looking at running the WINE programs under Windows can
> you take a look at the uninstaller program? When I build this program
> with Mingw or MS_VC and try to run it under Windows it crashes. It
> seems somehow it has a pro
Hello Pavel,
While you are looking at running the WINE programs under Windows can
you take a look at the uninstaller program? When I build this program
with Mingw or MS_VC and try to run it under Windows it crashes. It
seems somehow it has a problem loading the registry entries in the
uninstall key
Hello Pavel,
You can build the programs only also using the makefiles. You dont need
to use WINEs dlls or import libs. You can just run make programs or cd
to programs and type make.
Thanks
Steven
--- Pavel Roskin <[EMAIL PROTECTED]> wrote:
> Your instructions mention building DLLs. I'm not usi
Steven Edwards <[EMAIL PROTECTED]> writes:
> OK so we know the DPA_Create problems are not just in Mingw. Can we do
> something about this now?
You probably need a more recent comctl32.lib. I definitely have these
functions in mine.
--
Alexandre Julliard
[EMAIL PROTECTED]
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Are there such beasts? I didn't know this is a Wine extension...
> But even if it is, one thing we can do is to integrate the
> bin2res into the build process. We can place the embedded data
> inside comments, and run bin2res before compiling an .rc
On Wed, 24 Sep 2003, Richard Cohen wrote:
> Provided you don't care about delay-loading libraries, you can already
> compile the programs with winegcc. Here's the patch
+$(MODULE).so: $(ALL_OBJS) $(RC_SRCS:.rc=.res) Makefile.in $(WINEWRAPPER)
+ $(RM) $(BASEMODULE)
+ $(WINEGCC) -m$(AP
On Wed, 24 Sep 2003, Steven Edwards wrote:
> Most of it should already build under Cygwin as cygwin1b apps. just
> $ ./configure && make tools && cd dlls && make
The difference is that I'm compiling Wine programs without Wine libraries,
let alone DLLs. Only a very limited set of libraries is com
Most of it should already build under Cygwin as cygwin1b apps. just
$ ./configure && make tools && cd dlls && make
You will have trouble with kernel32 and ntdll.
Also there is a patch to build Wineserver on cygwin floating around.
If you want to build apps that are linked to msvcrt.dll rather th
OK so we know the DPA_Create problems are not just in Mingw. Can we do
something about this now?
Thanks
Steven
> -- Build started: Project: comctl32_test, Configuration: MSVC
> Headers Win32 --
>
> Linking...
> dpa.obj : error LNK2019: unresolved external symbol
> [EMAIL PROTECTED]
> r
On Wed, 24 Sep 2003, Alexandre Julliard wrote:
> No, it's here so that you can compile with other resource compilers
> that don't support having binary data inline. It could be changed to
> #ifdef __WRC__ though.
Are there such beasts? I didn't know this is a Wine extension...
But even if it is,
Jon Griffiths <[EMAIL PROTECTED]> writes:
> Yes, they are called more than once in the file, so stdcall produces
> smaller code (no need to duplicate the argument stack pops).
Please don't do that. Internal functions should use standard C calling
conventions. We don't care about two bytes of extr
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> I'm not sure why we had those defines in there. In general, we try to avoid
> defines like the plague in the Wine tree, so your patch is much appreciated.
> It seems that was some code the initial developers had in there for their
> own testing, and
[EMAIL PROTECTED] writes:
> So, what I'm wondering now is: 1) Should I bother finishing it? OSS is
> working fine for me again, and if someone else is going to fix the existing ALSA
> driver, and 2) if the answer to question 1 is 'yes', then what is the proper
> protocol for submitting such
I have recently noticed the large number of Stub DLLs being Added to
wine with minimal functionality, for example Msi, MSHTML (they don't
work for me in any case). These additions have not for the most part
been accompanied with a new "native, builtin" entry in samples/config.
Due to the forthcomi
Pavel Roskin wrote:
I have looked at winegcc source and it seems it will greatly improve
portability. I think it's a good idea to switch to winegcc first.
Provided you don't care about delay-loading libraries, you can already
compile the programs with winegcc. Here's the patch
--
Richard
diff -u
On Wed, 2003-09-24 at 08:26, [EMAIL PROTECTED] wrote:
> I was planning to submit it as a separate driver, since its architecture differs
> significantly from the existing one. The main differences are: support for
> "hardware" secondary buffers with ALSA, not Wine, doing the mixing; and the use
>
Hiya,
> Should this not be #define szResLen (sizeof(szRes)/sizeof(WCHAR) -
1) ?
Sorry, I must have dozed off. You are of course right, I'll resend in
a minute. Good spotting!
Jon
=
"Don't wait for the seas to part, or messiahs to come;
Don't you sit around and waste this chance..." - Li
Hiya,
> Is there any reason for changing the calling convention of these
> two functions?
Yes, they are called more than once in the file, so stdcall produces
smaller code (no need to duplicate the argument stack pops).
Similarly any function thats only called once can be explicitly
inlined for s
> since 0 is a wrong console handle (in this case), we don't care about
> actual c value.
But this causes a problem with winetests.exe, on win2k3 when running the tests, I
get a msg box saying
Microsoft Visual C++ debug library
Debug Error!
Program: C:\(Location of kernel32_tests here)
Module: C
On September 24, 2003 03:47 am, Pavel Roskin wrote:
> I have looked at winegcc source and it seems it will greatly improve
> portability. I think it's a good idea to switch to winegcc first.
>
> Thoose who compile large projects with Wine are not likely to abandon the
> Windows version, so it's he
> So, what I'm wondering now is: 1) Should I bother finishing it? OSS is
> working fine for me again, and if someone else is going to fix the
existing ALSA
> driver, and 2) if the answer to question 1 is 'yes', then what is the
proper
> protocol for submitting such a substantial code change.
I have hardware secondary buffers almost working with OSS and
soundcards that supports multi opens. I haven't had the time to finish
it lately but I would like to see how you handled some of the dsound.dll
issues.
[EMAIL PROTECTED] wrote:
> > I'm trying to improve winealsa's sound quality, and I
On Wed, 24 Sep 2003, Dimitrie O. Paun wrote:
> On September 23, 2003 11:59 pm, Pavel Roskin wrote:
> > For example, winefile.exe needs "-luuid" in MinGW because it provides
> > IID_IDataObject. In Wine, IID_IDataObject is defined in
> > include/objidl.h and a constant number. Wine doesn't have u
> I'm trying to improve winealsa's sound quality, and I have found a way. And
> I think I should make some checks in configure which I am totally unaware
> of. If everything go smooth, the patch will be sent out within several days.
A few weeks back, I got fed up with the winealsa driver not worki
39 matches
Mail list logo
