ReactOS/Mingw32 port

to fix it for our port? 3. Everything else I'm still new to the whole programming thing so I'm open for suggestions from everyone. If anyone has a better way of doing the port rather then #ifdef/#endif let me know. I'm going to start submitting patches to the headers today. Thanks Steven Edwards

RE: Patch to make wcmd compile on mingw/reactos

Ok I'll change it and resubmit it now. What about in the headers and dlls where we need to #ifdef? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Francois Gouget Sent: Sunday, January 27, 2002 4:29 PM To: [EMAIL PROTECTED] Cc: Isolation Subject: Re:

RE: ReactOS/Mingw32 port

.def files could either be generated from the .spec file, or winebuild could be modified to work with .def files. But in any case we should not have to maintain the same information at two different places. Ok no problem, I will take a look at that and see what I can come up with Binary

RE: ReactOS/Mingw32 port

Well, eventually I would like to see the the three projects (WINE/MinGW/ReactOS) use the same headers. IMO all three projects have incomplete and messy Windows headers. If the same headers were used, there would be no need for #ifdefs _PROJECT_NAME_ in them. Of course this would take a

Re: A new SDL back-end we've been toying with

You might want to take a look at microwindows if you want GDI/framebuffer However, keep in mind that Microwindows can be had at either MPL and GPL licenses. True, but you might be able to get them relicense certain parts for wine. __

Re: Support for generation of .def files from .spec files

--- Dmitry Timoshkov [EMAIL PROTECTED] wrote: Hello. Changelog: Dmitry Timoshkov [EMAIL PROTECTED] Support for generation of .def files from .spec files. This is great. I wont have a chance to try it out untill monday. Hopefully it will make it in to the tree. Thanks Steven

RE: Some more MSVC fixes

Platform Compilers BinFmt Headers - -- --- Linux gccELF Wine *BSD MSVC PE MS Solaris BorlandReactOS(?) Cygwin There are very little changes needed for the ReactOS port and only one or 2 ReactOS specific

Re: Wine license change

This little offtopic butWhat ever happend to TWINE? Is there anything of TWIN left that would be used moves to LGPL? Steven __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com

RE: Wine license change

So lets get this straight, if no one wants to change to the LGPL you'll fork the code? I don't have anything necessarily against the LGPL, but your email sounds all wrong. I don’t see how there can be a problem here. The current license allows anyone to do whatever they please with the code. You

RE: Wine license change

As someone with absolutely no connection to anyone at Codeweavers, I think Codeweavers' actions over the past two years or so more than sufficiently establishes the fact that they deserve to be given the benefit of the doubt in regards to statements like these. You can agree or disagree with

RE: (FWD) Announcing wineconf 2002

-Original Message- From: Uwe Bonnes [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 07, 2002 3:58 AM To: Steven Edwards I intend to go. Cool, see you there. _ Do You Yahoo!? Get your free @yahoo.com address at http

RE: Lindows.com and open source

Is there anyway we can see a list of the current people that have committed to show? Thanks Steven _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

RE: License change vote results

On 2-19-02 Patrik Stridvall Wrote Another thing. It is not nessary to have the whole of wine under the same license. For example the header files (wine/include/*.h) might be appropriate to have under the current license or even under public domain to facillitate sharing with other projects. I

Re: Notepad2. Command line processing

Also it has never been tested on Windows and has probably been broken by various 'fixes'. Maybe I should enter a new bug report? Unfortunately I don't have time to go in and look at it myself. No it has been tested on windows. =) we ported it and winemine as part of the ReactOS port.

RE: Artilcle - loading Windows DLL's under Linux

I'm not one to feed the trolls but hey what the hell... It is not legal to do this. You can't change the license on existing code. If it was originally licensed under the WINE X11 license, you cannot legally change that. Which is a good thing. No one should be allowed to stamp a virulent

RE: Fixing winebuild to (almost) work on Windows

I was able to get it to compile but not work on mingw. Did you build libwine_unicode as a dll for windows? I think it is needed for winebuild and wrc. How are you working with the resource files under MSVC, does it support wine resources? Currently windress pukes for me and I've had to use binary

GetSysColorPen in MSVC port

Hello Patrik, I've been having trouble making use of some of the wine dlls in our mingw due to the internal wine function GetSysColorPen. Have you been able to test any of the wine dlls under windows with MSVC? Do you have the same problem? We are planning on implenting this in our user32.dll

wineconf

are you attending wineconf? Thanks Steven __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/

_snprintf vs snprintf + proposed patch

Hello, When working on my port of wrc to windows I had to change snprintf to _snprintf in ppy.y on line 294 to build under mingw. I checked the msdn and didn't find anything on snprintf or _snprintf so I don't know if this patch will work for building under visual studio. Do I need to make a

RE: Status of Wrc port to mingw

Uwe Somewhere in the Wine compile on Linux these 2 shift/reduce conflicts emerge too. I've just now been able to get wrc to compile and work under windows. I think the version Of bison or byacc I was using was puking when it hit these conflicts. I'm going to make clean Tonight and give it

RE: _snprintf vs snprintf + proposed patch

vs snprintf + proposed patch Steven Edwards [EMAIL PROTECTED] writes: Do I need to make a check for HAVE_SNPRINTF? I'm using msys and mingw so I can write a configure check if that is what is needed. Yes, you should add a configure check and probably a #define in wine/port.h. Check how Patrik

Lindows developer information

Hello Michael, At wineconf Michael Robertson said that everyone would be registered as lindows developers so we could get access to the preview releases. What do we have to do to get registered. Thanks Steven _ Do You Yahoo!? Get your

Re: Why Wine is like playing the guitar

presentation on the Jscript.dll interface to Seamonkey. Some of the newer software loads Internet Explorers MSHTML.DLL for rendering and I belive that this software with a little help from wine could run better with tigher Mozilla Intergration. Thanks Steven Edwards Think Outside the Box

Re: Lindows developer information

And how do we avoid to fall under their stringent NDA? -- Uwe Bonnes Good point, sorry for the waste of bandwith. Steven Think Outside the Box __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage

Re: Why Wine is like playing the guitar

1. Office (Word, Excel, PowerPoint, Outlook.) 2. Internet Explorer. 3. AOL 4. TuboTax 5. Quicken/QuickBooks 6. Lotus Notes 7. All of the P2P software 8. Juno 9. Act 10. The Palm Desktop Plus tons of games I forgot to add chat clients. Move everyone from AIM/MSN/ICQ to Trillian

FW: cygwin/wine port

Hello Dimi, At wineconf you said you did the initial work on the cygwin port and I was wondering if I could get some help from you on it. I have been able to build libwine_unicode.dll wrc.exe and winebuild.exe under cygwin and mingw but I have had to do some tweaking of the makefiles and I am

Re: Winebuild on Windows

spec32.c contains the code to build the *.def's from the .spec.c. This patch fixes this right? Also when I try to use winebuild to build the *.def currently under win32, it wont work because its still trying to look for a *.so instead of a dll when a import library is listed. The problem is in

RE: DIB engine

I don't expect my comments will add much to this discussion because of my lack of coding ablity but this something ReactOS is going to need also. Is the following accurate, complete, etc? Comments? Other ideas? Any volunteers? I will help with documentation/testing on this if that is

Uninstaller issues on windows

Hola Andi, I've built the uninstaller under mingw32 but have been having problems getting it to work. It will crash shortly after startup. Is it being developed on win32 or is it wine only? If you don't mind supporting it on windows I will send you a full bug report. Thanks Steven

Review - Winnt.h warning patch for mingw32

This shuts up some compiler warnings on mingw but I don't know if my syntax is right. I know the rules about ifdef and ifndef but you guys said there was exceptions for the compilers so I figured I would check. Like I said I am still learning here so if this isnt right please flame away.

RE: posting wineconf info to slashdot?

When is the reactos presentation going to be put up? I know it wasn't the greatest in the world but we were on the guest list. =P -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Michael Cardenas Sent: Thursday, April 04, 2002 8:27 PM To: [EMAIL

RE: Running tests on windows

I use mingw with the wine headers for the winelib applications and dlls and it worked fine a few months back. Please use the WINELIB headers. We are using wine as our Win32 subsystem under reactos and I want to keep it as self-contained as possible. Mingw32s headers are very incompleate. This is

Another Minor Mingw32 Patch

This one could have a configure check but I havent had the time to learn How to properly write one and mingw is the only platform I know of that doesn't have ftruncate support. If anyone has the time and wants to help I have about 4 or 5 things I need ./conf checks written for.

Another warning fix for Mingw32

Same as last, if someone wants to help write a conf check by all means. Changelog: If the platform isnt MingW32 then define MAX_PATH cvs diff -u windef.h Index: windef.h === RCS file: /home/wine/wine/include/windef.h,v retrieving

Send the first two mingw32 patches to /dev/null and use these instead

Sorry about that. If you decide to apply them use this instead. I messed up and used CFLAGS=-D_MINGW_ instead of __MINGW__ cvs diff -u windef.h Index: windef.h === RCS file: /home/wine/wine/include/windef.h,v retrieving revision

Last patch for Mingw32 Warnings

Once again if someone wants to help I only have one warning left to fix. Changelog: More Mingw32 warning fixes cvs diff -u winnls.h Index: winnls.h === RCS file: /home/wine/wine/include/winnls.h,v retrieving revision 1.32 diff -u

Question about Warning when building wine under Cygwin/Mingw/MSYS

Anyone have any idea what to do about this? mingw32-gcc -c -I. -I. -I../../include -I../../include -D__MINGW__ -D_WINDOWS - DWINE_NOWINSOCK -Wall -mpreferred-stack-boundary=2 -DSTRICT -DNONAMELESSUNION -D NONAMELESSSTRUCT -D_REENTRANT -o regedit.o regedit.c In file included from

RE: Question about Warning when building wine under Cygwin/Mingw/MSYS

Thanks I will have a look at that. With typedef long long __int64; being the problem on line 47. Could it be that mingw32 simply doesn't understand long long ? (probably the second long confuses it into an empty declaration). If so, either find the real type name of long long that

Last header patch for Mingw32 I think (wingdi.h)

cvs diff -u wingdi.h Index: wingdi.h === RCS file: /home/wine/wine/include/wingdi.h,v retrieving revision 1.69 diff -u -r1.69 wingdi.h --- wingdi.h3 Apr 2002 22:08:27 - 1.69 +++ wingdi.h25 Apr 2002 16:48:19 -

Port.h issue with mingw

I need help with fixing this too. ../include/wine/port.h:175: parse error before `pread' ../include/wine/port.h:175: warning: type defaults to `int' in declaration of `p read' ../include/wine/port.h:175: warning: data definition has no type or storage clas s ../include/wine/port.h:179: parse

RE: Last header patch for Mingw32 I think (wingdi.h)

diff -u -r1.69 wingdi.h --- wingdi.h3 Apr 2002 22:08:27 - 1.69 +++ wingdi.h25 Apr 2002 16:48:19 - -24,6 +24,14 extern C { #endif +#ifdef __MINGW__ +#undef _MAX_PATH +#undef _MAX_DIR +#undef _MAX_EXT +#undef _MAX_DRIVE +#include

RE: Send the first two mingw32 patches to /dev/null and use these instead

Index: windef.h === RCS file: /home/wine/wine/include/windef.h,v retrieving revision 1.62 diff -u -r1.62 windef.h --- windef.h10 Mar 2002 00:02:34 - 1.62 +++ windef.h25 Apr 2002 02:09:36 -

Status of building Wine under Cygwin/Mingw

Note: send any spelling/grammer errors to /dev/null. I've compiled a little list of things that are still lacking on the port of wine to mingw/msys/cygwin. Unless I mention cygwin as the target it can be assumed for the purpose of this doc I am speaking about a mingw target. About 5 or 6 months

Ntddk.h wcstol question

On some of the dlls this is a problem. Wine - include/ntddk.h INT __cdecl wcstol(LPCWSTR,LPWSTR*,INT); Mingw - stdlib.h longwcstol (const wchar_t*, wchar_t**, int); ReactOS - msvcrt/stdlib.h longwcstol (const wchar_t* wsNumber, wchar_t** pwsAfterNumber, int nBase); Anyone have a

Issues building the spec.o on win32 with mingw

I get this on almost every *.spec.o Administrator@LAPTOP /cygdrive/d/src/winehq/wine/dlls/commdlg $ make PATH=../../unicode:$PATH ../../tools/wrc/wrc -I. -I. -I../../include -I../../ include -o rsrc.res -r rsrc.rc PATH=../../unicode:$PATH ../../tools/winebuild/winebuild -L../../dlls -o comm

Re: Issues building the spec.o on win32 with mingw

: Steven Edwards [EMAIL PROTECTED] writes: Any ideas? I really don't need the spec because I can do a -l if I can build the .a for ntdll and a few others. I can use dlltool with the *.defs and then I only need winebuild to make the *.defs. Only problem is winebuild wants so's not dll's when

RE: MAX_PATH mess fix

I have committed a different fix that I think should work too, please give it a try. We should be 100% Windows-compatible now so if it still doesn't work I'd say the problem is in Mingw. Your fix worked for all of the missing MAX_PATH errors in winnls.h and wingdi.h but I still get one

RE: MAX_PATH mess fix

IMO it's a mingw problem, stdlib.h is not supposed to define MAX_PATH, only _MAX_PATH. Ok thanks, I'll go bug them for a while. Steven Every revolution was once a thought in one man's mind - Ralph Waldo Emerson

Ftruncate check

I saw it was not applied. What was wrong with it? Thanks Steven Every revolution was once a thought in one man's mind - Ralph Waldo Emerson

PATCH - makedep

I don't know if this will cause any problems for other platforms but it works here. Of course so did my last dirty hack so can someone point out a better way? According to http://www.delorie.com/djgpp/doc/libc/libc_95.html if the system has ftruncate it just calls it. If this isnt cool then

RE: wine/ ./winedefault.reg dlls/Makefile.in dlls/ ...

Who's Hidenori? Is this code being moved somewhere else? If the code was licensed X11 at one point are we still free to use it? Every revolution was once a thought in one man's mind - Ralph Waldo Emerson

RE: More MSVC fixes

How are you planning on linking the dlls/resources once wine is up 2 date on MSVC? Can MSVC build wrc resources and link them? Thanks Steven Every revolution was once a thought in one man's mind - Ralph Waldo Emerson

Send PATCH - check for ftruncate/fix for makedep when missing ftruncate (mingw) to /dev/null

I hit send when I was trying to save. I will be sending the new patch tonight. Thanks Steven Every revolution was once a thought in one man's mind - Ralph Waldo Emerson -Original Message- From: Steven Edwards [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:53 PM

FW: PATCH - check for ftruncate/fix for makedep when missing ftruncate (mingw)

Changelog: More Mingw work. configure, configure.ac - Configure check for ftruncate. configure, configure.ac - Configure check for chsize port.h - Use chsize instead of ftruncate if present. port.h - Disable use of HAVE_PREAD

RE: Issues building the spec.o on win32 with mingw

I'm sending this to all of you because I'm a little behind on my mail and these two issues go hand in hand Winebuild wrc. Well, they clearly say that .previous is ELF specific. Don't know why, but it is... However, do we really need it? I couldn't spot any place were we don't know the

Re: More MSVC fixes

I would argue that compatibility with MS' rc is more important... I would too. About the resources, Eric Kohl told me one time the plain txt rc was due to endiness issues on non-x86 platforms. I dont really see how thats a issue if the platform supports GIF/JPEG but I dont understand how alot

Re: Issues building the spec.o on win32 with mingw

You really can't use the .spec.c file. The result won't be a proper PE dll, and you would need the Wine loader to patch things up at run-time to make it look like a real dll. It's much easier to build a true PE dll in the first place. Ok cool, once I send the last of my current patches in

Re: More MSVC fixes

Besides, if someone really wants to use the MS compiler, it would be pretty trivial to enhance bin2res to generate MS-compatible files from the Wine sources. There's no need to ship binary files for that. OK, I'm convinced :) I fact, I don't care much about MS rc, is just that I

Re: More MSVC fixes

I will start a bug in bugzilla to address this issue. (wrc does not generate resources that can be used on Mingw and MS_VC) http://bugs.winehq.com/show_bug.cgi?id=645 __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness

RE: More MSVC fixes

I'm not sure I understand the problem. wrc generates .res files that should work just fine with MS VC or windres. Why doesn't this work? The last time I tried(two months back) it wouldn't work. I will double check tonight and email you a full report of my attempts/problems. Thanks Steven

Problems with the new -DNO_LIBWINE on i386-mingw

Should I need to build libwine if I'm just building tools, programs and dlls? I have no need of wineserver for the mingw port but I will need it for the cygwin port. Here is the command line I have been using with the new port.h changes ./configure --host=mingw32 --target=mingw32 --build=mingw32

RE: A little configure change help needed for the mingw/msys port.

I'd suggest something like that: Thanks a lot, your patch works perfect. With this command I can now properly configure. ./configure --host=mingw32 --target=mingw32 --build=mingw32 CFLAGS=-D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK CC=gcc -mno-cygwin CXX=gcc -mno-cygwin There are still a few

RE: Running unit tests on Windows

Jakob (I guess somewhere in here the project of keeping mingw, ReactOS Jakob and Wine headers in sync come into play... BTW I've noticed the Jakob ReactOS people seem to feel a little ignored by Wine.) My statement about the headers was a little to off cuff. The wine project has been

RE: Running unit tests on Windows

jakov@black:/tmp jakov@black:/tmp i586-mingw32msvc-gcc file.c /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mi ngw32msvc/lib/libmingw32.a(main.o)(.text+0x8f): undefined reference to `WinMain@16' There is no main statement in file.c Every revolution was once a thought in

Re: Breakthrough! Can now crosscompile unit tests!

--- Jakob Eriksson [EMAIL PROTECTED] wrote: On Thu, May 09, 2002 at 08:01:51PM -0400, Steven Edwards wrote: jakov@black:/tmp jakov@black:/tmp i586-mingw32msvc-gcc file.c /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mi ngw32msvc/lib/libmingw32.a(main.o)(.text+0x8f

Re: wine/ ./configure ./configure.ac include/confi ...

I'm afraid that this is the wrong solution to this problem: People using sNprintf do this sometimes for security reasons. Just ignoring the length is very likely to cause some problems with applications that would have been otherwise secure (I'm thinking of chatclients etc). snprintf

Re: Breakthrough! Can now crosscompile unit tests!

What I want is for the Wine configure to detect that mingw32 is present, then modify Makefiles so that when make tests is run, EXE-files are modified. I also don't want to do #ifdef REAL_EXE or whatever in every c-file, I want all that to happen automagically in wine/test.h ! I want the

RE: Bug tracking organization

developer stuff metabug WineLib winedbg regression testing/test suite metabug msvcrt, msvcrt20, crtdll Misc. metabug (for other stuff) twain, winaspi others metabug (in order to deposit bug reports of alien wine packages here) I would like to see the

Uninstaller problem on mingw port

Hello Jeremy, Andi suggested I email you about my issues with uninstaller under mingw. The main unstaller window will render but be blank and then the program will crash when it gets to this line /*-- -- ** Handle

Re: Breakthrough! Can now crosscompile unit tests!

I couldn't make any of the unit tests compile... but that's ok. Stand by for my master plan! :-) With the latest patch I can compile a blank dll but not a real one. Ntdll and libwine do not compile right and they have the exports needed for every other wine/dll, I will be submitting a bug

RE: Uninstaller problem on mingw port

You know, that's not quite true... ;) I just said that AFAIK it was him who added that line. Ah well, nevermind. Ok so mabey I took it as you implying to go ask Jeremy. =) Steven: did you check whether cmdline contains a legitimate pointer at all ? (e.g. via IsBadReadPtr() or so...) No I

RE: Breakthrough! Can now crosscompile unit tests!

This should be fixed by my latest patch too. At least it seems to work for me when cross-compiling, I have sucessfully built winemine.exe with mingw (you need to remove ntdll and libwine from the link to make it work, I'll try to fix that shortly). Kickass. I just built winemine with no

RE: Fix for commdlg on Mingw

I don't think that it's a good idea. Apparently Mingw uses msvcrt.dll as its C run-time library and wcstol is imported from there. It would be much better to use functions provided by Wine dlls as much as possible. Especially in the cases when wcstol is imported by kernel, user or gdi,

RE: Fix for commdlg on Mingw

them in as replacements on NT/2K and see what breaks. Wineserver emulates Windows NT/2K be default right? No, wineserver does not emulate anything. So once ported, will the higher level dlls from wine function on a Windows/ReactOS system? Ole*, Commdlg, Comctrl, shfolder, shlwapi, mapi,

RE: Fix for commdlg on Mingw

And the very next question arises how to resolve conflicts with prototypes provided by an underlying system? I will ask this of the reactos developers. Every revolution was once a thought in one man's mind - Ralph Waldo Emerson

Breakdown and Status of wine/dlls on the mingw port

Ok folks here is the break down of the results from my attempt build most of wine/dlls on mingw. You can build almost all of the object files for every wine/dll but cannot link currently due to the Makefiles looking for a ntdll and libwine import. I did not attempt to build any of the

RE: Fix for commdlg on Mingw

Sure, all Wine dlls which use only win32 APIs for their needs should work on ReactOS. Besides dll separation there are other issues: direct use of fork, getpid and similar unixisms, direct access to unix file system (DOSFS_GetFullName/open/mmap/etc), direct access for unix devices. I

conflicting types for `usleep' in wine/port.h and libwine/port.c

I don't guess we are building libwine.dll on mingw but I was playing with it just the same when I came to this. Is this to be expected? gcc -mno-cygwin -c -I. -I. -I../include -I../include -D__MINGW__ -D_WINDOWS -DW INE_NOWINSOCK -Wall -mpreferred-stack-boundary=2 -D__WINE__ -DDLLDIR=\/usr/loc

Getpagesize in libwine port.c on windows target

I have two fixes for missing getpagesize on windows. Once this is done the only thing that is stopping me from building libwine is the missing refrences to _assert and _errorno. 1. In xemacs they #define getpagesize() 4096 and it seems to work. 2. The other fix would be to use getsystem_info.

Mingw devel stuff Part2

Sorry about that I hit the send button to soon. OK when I try build shlwapi.dll I'm getting this Administrator@LAPTOP /cygdrive/d/src/winehq/wine/dlls/shlwapi $ make dllwrap --add-stdcall-alias --def shlwapi.spec.def --implib shlwapi.a -o shlwapi .dll ordinal.o path.o reg.o regstream.o

Mingw Port Information and Questions

OK so we the latest changes I do need to build libwine.dll right? I can if I link it to msvcrt.a but ig I don't I get the following Administrator@LAPTOP /cygdrive/d/src/winehq/wine/library $ make dllwrap --add-stdcall-alias --export-all --implib libwine.a -o libwine.dll debug .o errno.o ldt.o

RE: Mingw devel stuff Part2

Does it work better with this patch? I'm having touble applying the patch, should it just be the standard Patch -p0../patch.diff This is what happens on every part patching file `include/wine/debug.h' patch: malformed patch at line 17: -102,11 +95,11 Thanks Steven Every revolution was

RE: Mingw devel stuff Part2

Does it work better with this patch? Yes I have manualy applied the patch and my results are much better now. I have just done a rebuild of unicode and library with no problems other then the normal libwine.dll needing to be linked to msvcrt Here is the output from building shlwapi dllwrap

Re: Mingw devel stuff Part2

After that patch I am also able to compile these dlls Comcat.dll Crtdll.dll Msisys.ocx Netapi32.dll Riched32.dll Serialui.dll Twain_32.dll Wintrust.dll I know that some of them are mostly stubs but its still a good start. I understand WINEs crtdll just forwards call to msvcrt.dll but will this

RE: Native User32

See my other email about build system changes. Other wine dlls are dependant on wine's user such as comctl32 for The GetSysColorPen function that is not part of the Win32api. Thanks Steven Every revolution was once a thought in one man's mind - Ralph Waldo Emerson

Requested Change to the build system

Hola and Thanks for everything so far in getting the Mingw port rolling. Doing my work on getting shlwapi.dll built I noticed the missing imports from user32 wvsnprintfA@16 and wvsnprintfW@16 in libuser32.a. I was going to submit a patch to the mingw developers for the Win32api package that

Send that last email to /dev/null

I see wvsnprintf16 in user32 is marked (Not a Windows API) also. So we have (user32) GetSysColorPen/wvsnprintf and (ntdll) wine_get_unix_file_name That need to be fixed for mingw. Thanks Steven Every revolution was once a thought in one man's mind - Ralph Waldo Emerson

RE: Requested Change to the build system

Ok I will hold off on a patch for a implib rule untill the new binutils Is released. I can do without it for now away, as there are still like 50 other misc bugs that we can hunt down and only 4 or 5 dlls need the Ntdll and shlwapi import libs. Like I said its manly something that would Be nice

Part 1 - Mingw Port Status 5-20-02

Here are the results from my latest attempt to build wine under mingw. We can build alot more now but most of these are still manly stubed dlls. Anywhere it has (needs msvcrt import) I will submit a patch to the Makefile.in with my next set of patches. Also anywhere it has missing -lshlwapi

Part3 - Mingw Status 5-20-02

ddraw.dll - (needs MSVCRT import to get rid of _assert) dllwrap --add-stdcall-alias --def ddraw.spec.def --implib ddraw.a -o ddraw.dll c onvert.o dclipper/main.o ddraw/hal.o ddraw/main.o ddraw/thunks.o ddraw/user.o dp alette/hal.o dpalette/main.o dsurface/dib.o dsurface/fakezbuffer.o

Again Part2 - Mingw Port 5-20-02

Fails - I will need to retest comctl and comdlg because of the GetSysColorPen Changes. ole32.dll - (Mingw: missing -lntdll, needs msvcrt import do to _assert usage) dllwrap --add-stdcall-alias --def ole32.spec.def --implib ole32.a -o ole32.dll a ntimoniker.o bindctx.o clipboard.o compobj.o

End Of Flood Part 4 - Mingw Port

rpcrt4.dll - gcc -mno-cygwin -c -I. -I. -I../../include -I../../include -D__MINGW__ -D_WINDO WS -DWINE_NOWINSOCK -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_RPCRT4_ -D_ REENTRANT -o rpcrt4_main.o rpcrt4_main.c rpcrt4_main.c: In function `UuidCreate': rpcrt4_main.c:107: variable `last' has

RE: Part 1 - Mingw Port Status 5-20-02

Actually none of the Wine dlls should import msvcrt, at least not on Unix. We could add the import only for the mingw case, but I'd argue that the mingw linker should be doing this automatically. Ok I will add that to the list. I will be submitting patches/bug reports To the mingw team in

RE: Again Part2 - Mingw Port 5-20-02

Lots of errors come from the 16 bit support I think we should also try to have a configure option like --disable-16bit-support or something this would be very useful for a WineCE port but of course, that's not an easy quick task :-( It would be nice to be able to disable the win16

Quick question on the Cygwin/Mingw port

Hola, I'm on the road traveling till Monday so I sent the question here rather then cygwin support because I figured someone here has to have a little cygwin and mingw experience. I'm using cygwin to host my mingw WINE devel with --target=mingw --host-mingw --build=mingw -mno-cygwin and

V0.1 WINE Mingw and ReactOS porting and status guide.

I am out of town untill Monday evening but I've been trying to get my documentation work done while on the road. If anyone is interested here it is. It has a list of some of my current bugs plus room for people to test and play. All flames will be dumped in /dev/null on my return =P Thanks

Request for small build system change

When I use cygwin or msys to build wine/tools I need to link to wrc and wmc to libberty.a. I've tried to write a little fix for it but havent had much luck and still have a few other things I am working on. Thanks Steven Every revolution was once a thought in one man's mind - Ralph Waldo

RFC - patch for psapi and missing imports on Mingw target

This kind of a dirty hack but just a idea and it shouldn't have a effect on cygwin as it will use the win32api package also. Mabey a better name then MINGW_IMPORTS can be used. This patch allows psapi.dll to be (almost) built. Mingws libkernel32.a doesn't contain the import information for the

RE: Second current CVS compile failure

/home/albertel/t1/wine/dlls/comcat/information.c:392: undefined reference to `swprintf' collect2: ld returned 1 exit status make[2]: *** [comcat.dll.so] Error 1 I get this too. I though it was mingw specific. Importing ntdll or msvcrt will fix it. Thanks Steven Every revolution was once a

Re: DOS memory Question..... or How to increase base memory for DOS apps

I belive this is what the TWIN project did for there x86/Win Emulation based on WINE. TWIN is LGPL and wine has never been able to use that code untill now. - do everything cleanly and even then, it may not fix every dos app, or even worse it could break some non-dos app in unforeseen

  1   2   3   4   >