Menu
▾
▴
reactos-kernel
|
From: Jason F. <jas...@ya...> - 2002-05-19 22:30:05
|
Ok... now that things seem to have quietened down a bit again, let's take up the issue of restructuring our source tree. Here's what I have based on previous mails: apps/*: removing apps/test, move apps/system to subsys lib/bzip2: move to services/lib lib/crtdll: move to win32 module lib/dflat32: move to rosapps module (?) lib/fmifs: move to win32 module lib/msvcrt: move to win32 module lib/ole32: move to win32 module lib/oleaut32: move to win32 module lib/psapi: move to win32 module lib/shell32: move to win32 module lib/version: move to win32 module lib/zlib: move to services/lib lib/ole: move to win32 module lib/ole32: move to win32 module lib/rpcrt4: move to win32 module lib/psapi: move to win32 module (?) subsys/os2/*: move to os2 module subsys/psx/*: move to posix module * Move WINE related DLLs now? Input please Thanks - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Steven E. <Ste...@ya...> - 2002-05-20 02:58:11
Attachments:
Mingw and ReactOS wine porting guide.txt
|
>> * Move WINE related DLLs now? Well the WINE related stuff can really be blown away. We should keep the current makefiles But everything else in our wine tree can be zapped. We need to write a shell script to take the wine makefiles and convert them in to ReactOS makefiles. We still will not be able to use wine untill some internal non-win32 functions are fixed in the wine tree. I have put together a little guide for Wine/ReactOS hacking. Once we get a little more along I will break the guide up and make a Mingw Developer Guide for the WINE project and a ReactOS wine Hacker guide. I will email more tommrow I'm kinda in a rush. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Diego I. <ias...@ac...> - 2002-05-20 19:49:27
|
On Monday 20 May 2002 05:56, Steven Edwards wrote: > Well the WINE related stuff can really be blown away. We should keep > thecurrent makefilesBut everything else in our wine tree can be zapped. We > need to write ashell script to take the wine makefiles and convert them in > to ReactOSmakefiles. do you mind putting binaries dll's online, so people will be able to test them now on ms-win32 environments? will they work on win98? If I remember previous threads here, if I replace nt dll's on startup nt will restore them to the ms versions again, is a work around available? riched32.dll: are there stubs functions or is it <fully> working? Please update from wine's cvs, since I know that currently bidi is introduced into wine by IBM Israel and some users. I wonder how bad will it work ;) - diego -- The so-called lessons of history are for the most part the rationalizations of the victors. History is written by the survivors. -- Max Lerner |
|
From: Steven E. <Ste...@ya...> - 2002-05-20 19:57:45
|
> do you mind putting binaries dll's online, so people will be > able to test them > now on ms-win32 environments? will they work on win98? If I > remember previous > threads here, if I replace nt dll's on startup nt will > restore them to the ms > versions again, is a work around available? Some of them may work under 98 but I am not going to support it and neither is the Wine project. There is a fix for Windows2000 replacing the files, you will need to search google for "disable windows file protection" So you want to help me test? KICKASS. I will put a link up with the current binarys tonight. > riched32.dll: are there stubs functions or is it <fully> > working? Please > update from wine's cvs, since I know that currently bidi is > introduced into > wine by IBM Israel and some users. I wonder how bad will it work ;) Not 100% sure but if you want you can help me test everything. Here is the list of dlls we can compile with a Mingw host as of 5-20-02. Once again some of these are mostly stubs. avicap32.dll crtdll.dll crypt32.dll dciman32.dll imagehlp.dll imm32.dll mapi32.dll mpr.dll msdom.dll msimg32.dll msisys.ocx netapi.dll oledlg.dll olepro32.dll olesvr32.dll rasapi32.dll riched32.dll serialui.dll shdocvw.dll tapi32.dll twain_32.dll urlmon.dll winnls.dll winspool.drv wintrust.dll Builds with easy fix - comcat.dll (needs msvcrt import due to swprintf usage) dinput.dll (needs msvcrt import do to _assert usage) odbc32.dll (needs msvcrt import do to _assert usage) |
|
From: KJK::Hyperion <no...@li...> - 2002-05-20 22:38:48
|
At 21.46 20/05/2002, you wrote: > > Well the WINE related stuff can really be blown away. We should keep > > thecurrent makefilesBut everything else in our wine tree can be zapped. We > > need to write ashell script to take the wine makefiles and convert them in > > to ReactOSmakefiles. >do you mind putting binaries dll's online, so people will be able to test >them now on ms-win32 environments? will they work on win98? Not the core DLLs (kernel32, user32, gdi32), because they talk directly to the kernel >If I remember previous threads here, if I replace nt dll's on startup nt >will restore them to the ms versions again, is a work around available? Delete the copies in the dllcache folder of the files you want to replace: WFP won't be able to restore the original files without your intervention. Another trick involves cracking the WFP dll and setting some parameter in the registry |
|
From: Robert K. <ro...@ko...> - 2002-05-21 10:44:45
|
> > >If I remember previous threads here, if I replace nt dll's on startup nt > >will restore them to the ms versions again, is a work around available? > > Delete the copies in the dllcache folder of the files you want to replace: > WFP won't be able to restore the original files without your intervention. > Another trick involves cracking the WFP dll and setting some parameter in > the registry An elegant way around WFP is using these two commands in CMD >sfc /cachesize:1 reboot <- it is recommended but should work without >sfc /Purgecache > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: Jason F. <jas...@ya...> - 2002-05-26 19:55:07
|
Ok we can remove the WINE module.. but where to move those makefiles? Perhaps we should keep the WINE module just to keep things nicely organized? - Jason --- Steven Edwards <Ste...@ya...> wrote: > >> * Move WINE related DLLs now? > > Well the WINE related stuff can really be blown away. We should > keep the > current makefiles > But everything else in our wine tree can be zapped. We need to > write a > shell script to take the wine makefiles and convert them in to > ReactOS > makefiles. > > We still will not be able to use wine untill some internal > non-win32 > functions are fixed in the wine tree. > > I have put together a little guide for Wine/ReactOS hacking. Once > we get > a little more along I will break the guide up and make a Mingw > Developer > Guide for the WINE project and a ReactOS wine Hacker guide. > > I will email more tommrow I'm kinda in a rush. > > Thanks > Steven > > "Every revolution was once a thought in one man's mind" > - Ralph Waldo Emerson > > > This document should contain all of the information needed for you > to start > developing wine on the Mingw platform. Almost all information in > this guide > applys to both the Mingw on Cygwin and Mingw for ReactOS ports. > > This document assumes you are using cygwin to configure and build > WINE for > a Mingw Target. Cygwin is enviroment used due to a set of bugs > within the > Mingw Unix Enviroment MSYS. Msys may work however it, the ReactOS > build > system and and any other configurations are not supported by the > WINE project. > > > REACTOS DEVELOPERS: > The ReactOS Project will try to do quarterly imports of the WINE > tree after > each ReactOS release. > > If you need to import the WINE sources in to the ReactOS build > system or > want to build ReactOS with a newer copy of the WINE sources follow > these directions > > (1) Run importwineros.sh on the most current wine sources > (2) set the enviomental varible ROS_BUILD_WINE=1 > (3) Rebuild ReactOS sources as normal > > If you are adding funcationality to WINE, such as implementing a > function in > a WINE dll that is currently a stub, you MUST use the Cygwin on > Mingw enviroment > with the most current WINE sources. Any patches that add > funcationalty to the > WINE dlls MUST first be accepted by the WINE project and follow the > WINE projects > coding standards. > > DO NOT SEND REACTOS SPICIFC CHANGES TO THE WINE PROJECT. > YOU HAVE BEEN WARNED. =P > > Any ReactOS Spicifice changes in the REACTOS fork must be clearly > marked and > should not be used unless there is no other way to work around the > problem. > > Example: > #ifdef __REACTOS__ > ReactOS Spacific code > #endif > > > DEVELOPING WINE USING MINGW ON CYGWIN. > > To start hacking on Wine for Mingw, follow the directions at > www.winehq.com > to download the most current WINE sources. > > (1) ./configure --host=mingw32 --target=mingw32 --build=mingw32 > CFLAGS="-D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK" CC="gcc > -mno-cygwin" CXX="gcc -mno-cygwin" > > Note: you may also be able to add --disable-debug --disable-trace > flags to this command line. > > (2) make depend > > (3) make tools > > MAKE TOOLS BUGS: > BUG: libwine.dll needs to be linked to libmsvcrt.a and will fail > FIX: copy /usr/local/lib/mingw/libmsvcrt.a to > /usr/local/lib/libmsvcrt.a > add -lmsvcrt to wine/library/Makefile > > BUG: winedump uses mmap and munmap which Windows Lacks > FIX: Remove winedump from wine/tools/makefile > > BUG: wmc and wrc need to be linked to libberty.a (getopt, optarg, > optan) > FIX: add -liberty to wrc and wmc Makefiles > > BUG: Cygwins libberty.a is buggy > FIX: use the one from normal mingw > > (4) cd programs && make > > MAKE PROGRAMS BUGS: > BUG: regsrv and wineconsole fail > FIX: Remove them > > BUG: uninstaller is buggy on the mingw port > > (5) Make dlls > So we have (user32) GetSysColorPen/wvsnprintf and (ntdll) > wine_get_unix_file_name That need to be fixed. > These are not part of the Win32 and must be corrected in wine > > > > > shlwapi needs imports from user32 that are not part of the > win32api. > wvsnprintfA@16 > wvsnprintfW@16 > > We can currently build > comcat.dll > crtdll.dll > msisys.ocx > netapi32.dll > oledlg32.dll > riched32.dll > serialui.dll > twain_32.dll > wintrust.dll > > > > TODO: > - Wine Tree > Fix programs/uninstaller > Debugging and testing of Mingw port > Winehq Mingw develoepr HOWTO > > - ReactOS fork > Write importwineros.sh script to convert wine Makefiles to ReactOS > makefile's when doing a import. > Write ReactOS wine developer HOWTO > > - Cygwin > Email Cygwin developers about liberty.a issue when building as > mingw > > - Mingw > Email Mingw Developers about warnings in basetsd.h and stdlib.h > Send patch to Mingw Project about missing exports in user32 __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: Eric K. <ek...@rz...> - 2002-05-23 11:33:46
|
"Jason Filby" <jas...@ya...> wrote: > apps/*: removing apps/test, move apps/system to subsys As part of my current work on smss I wrote a dummy autochk.exe. Should I commit it to apps/system/autochk or somewhere else? How do you plan to organize the sysbsys directory? Btw, where will user-mode services be located in the cvs tree. IMHO, the services-directory is not the right place. It should be renamed to 'drivers' to minimize the confusion about the term 'service'. Eric |
|
From: Casper H. <ch...@us...> - 2002-05-23 12:31:37
|
tor, 2002-05-23 kl. 13:35 skrev Eric Kohl: > Btw, where will user-mode services be located in the cvs tree. IMHO, the > services-directory is not the right place. It should be renamed to 'drivers' > to minimize the confusion about the term 'service'. I agree. |
|
From: Aliberti E. <ea...@us...> - 2002-05-23 20:29:03
|
On 23 May 2002 at 13:35, Eric Kohl wrote: > > apps/*: removing apps/test, move apps/system to subsys I'd remove only Win32 test applications. Applications that test undocumented or system specific functionalities should be kept. > As part of my current work on smss I wrote a dummy autochk.exe. Should > I commit it to apps/system/autochk or somewhere else? > > How do you plan to organize the sysbsys directory? > > Btw, where will user-mode services be located in the cvs tree. IMHO, > the services-directory is not the right place. It should be renamed to > 'drivers' to minimize the confusion about the term 'service'. services.exe loads kernel mode modules and Win32 services. I probably lost any message in this thread, but is it expected to be turned into a native application that can load any service-like (W32), daemon- like (PSX), ...-like, via external helpers (svcsys.dll, svcscm.dll, svcdaemon.dll, ...)? |
|
From: KJK::Hyperion <no...@li...> - 2002-05-24 00:12:26
|
At 22.30 23/05/2002, you wrote: > > Btw, where will user-mode services be located in the cvs tree. IMHO, > > the services-directory is not the right place. It should be renamed to > > 'drivers' to minimize the confusion about the term 'service'. >services.exe loads kernel mode modules and Win32 services. I probably lost >any message in this thread, but is it expected to be turned into a native >application that can load any service-like (W32), daemon- like (PSX), >...-like, via external helpers (svcsys.dll, svcscm.dll, svcdaemon.dll, ...)? I like this approach. Same for csrss and winlogon, I hope |
|
From: Frank D. E. Jr. <fd...@ya...> - 2002-05-25 17:42:57
|
> I like this approach. Same for csrss and winlogon, I hope Uh... csrss IS the Win32 subsystem, so it is like... already native, I hope. ===== ======= Frank D. Engel, Jr. Please note my new address: fd...@ya... __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: KJK::Hyperion <no...@li...> - 2002-05-25 23:54:33
|
At 19.42 25/05/2002, you wrote: > > I like this approach. Same for csrss and winlogon, I hope >Uh... >csrss IS the Win32 subsystem, so it is like... already native, I hope. See "csrss explained" to see what I'm referring to |
|
From: Jason F. <jas...@ya...> - 2002-05-24 11:10:02
|
Hi Eric >As part of my current work on smss I wrote a dummy autochk.exe. >Should I commit it to apps/system/autochk or somewhere else? Sorry about the late reply. I see you already checked in autochk, that's good, because you'd probably know best where to put it. >How do you plan to organize the sysbsys directory? Pulling out psx* and os2* into their own modules, that's about it. Any other suggestions? >Btw, where will user-mode services be located in the cvs tree. >IMHO, the services-directory is not the right place. It should be >renamed to 'drivers' to minimize the confusion about the term >'service'. Yes we should rename it. - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Eric K. <ek...@rz...> - 2002-05-24 16:08:06
|
"Jason Filby" <jas...@ya...> wrote: Hello Jason! > Sorry about the late reply. I see you already checked in autochk, > that's good, because you'd probably know best where to put it. Okay! > Pulling out psx* and os2* into their own modules, that's about it. > Any other suggestions? IMO, we should create two more subdirectories in 'apps', 'apps/testapps' and 'apps/utils'. 'apps/testapps' will contain the test applications from the 'apps' directory, for example 'hello' or 'mutex'. 'apps/utils' will contain useful utilities for developers like 'objdir' or 'partinfo'. > >Btw, where will user-mode services be located in the cvs tree. > >IMHO, the services-directory is not the right place. It should be > >renamed to 'drivers' to minimize the confusion about the term > >'service'. > > Yes we should rename it. The 'services' directory should become the location for user-mode services, like rpcss and eventlog. Regards, Eric |
