- Ros-dev - ReactOS.org

RE: [ros-svn] [ion] 14801: Add GDB = 1 to makefile to compile-in theGDB Wrapper. These options will be better manged with rbuild
by Ge van Geldorp 25 Apr '05

25 Apr '05

> From: ion(a)svn.reactos.com > > Add GDB = 1 to makefile to compile-in the GDB Wrapper. These > options will be better manged with rbuild Any reason the inclusion of the GDB stub can't be keyed on the existing "DBG" var? I feel (pretty strongly) we should minimize the number of compile-time configs. Gé van Geldorp.

2 1

RE: [ros-svn] [ion] 14801: Add GDB = 1 to makefile to compile-in theGDB Wrapper. These options will be better manged with rbuild
by Casper Hornstrup 25 Apr '05

25 Apr '05

> -----Original Message----- > From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of > ion(a)svn.reactos.com > Sent: 25. april 2005 17:20 > To: ros-svn(a)reactos.com > Subject: [ros-svn] [ion] 14801: Add GDB = 1 to makefile to compile-in theGDB Wrapper. These options > will be better manged with rbuild > > Add GDB = 1 to makefile to compile-in the GDB Wrapper. These options will be better manged with > rbuild > > > Updated files: > trunk/reactos/config Experience has told us that with compile-time options come more compilation errors (and we have enough of those). Please compile it in always and make it a run-time option instead to avoid this. The extra bytes are well spent. Casper

1 0

rbuild status - need help finalizing
by Royce Mitchell III 24 Apr '05

24 Apr '05

rbuild has one bug ( that we're aware of ) blocking it from being ready to go live. Basically, both bootcd and livecd are halting with a "inaccessible_boot_device" after blue.sys. Would anybody be willing to look at it and help us figure out what we're doing wrong when generating the ISOs? Also, being this close, would everybody who cares please check out the rbuild branch for feedback before we go live? Here's the branch url: svn://svn.reactos.com/branches/xmlbuildsystem/reactos Thanks

5 11

Crash at shutdown ( killing Explorer ) in current CVS
by Jan Schiefer 24 Apr '05

24 Apr '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I hit the start menue entry to kill explorer. I'm running this on QEMU 0.6.1. -user-net is enabled. Then this problem appeared. Just look at the screenshot. I just want to report that problem. Greetings, Jan Schiefer! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCa4SYzC00UKXFdVcRAi8vAKCwVQKvLbisZ2P9qz+TFv5qzf+R0QCfbmwa 2+fVvDWgGnGWGeQ7u/TYkFA= =ow9s -----END PGP SIGNATURE-----

1 0

Kernel System Page Table
by Alex Ionescu 23 Apr '05

23 Apr '05

Hi Hartmut & Mm Experts, It seems that on ROS, every process has its own Page Table for the Kernel Area/System Table. This needs to be updated with MmUpdatePageDir all the time, and creates a bunch of annoyances in the Context Switching code too (for example, I can't check the trap frame for VM_MASK because at that time the Page Directory hasn't been changed yet. I could change it before but that would screw up the optimizations. Philip Susi and I have researched this and arrived to the common conclusion that every new Process's Page Table should share the same System Page Table. I'm not an expert so maybe I'm not explaining it properly, but the System Page Table shouldn't have to be "inserted/mapped" into every Process's Page Table, it should already be there, shared amongst all processes. I hope that made sense...if not, maybe Philip can fix up my explenation. Is it possible for any of the Mm guys to implement this properly? Thanks a lot.. Best regards, Alex Ionescu

3 4

Compile error with DBG=1 and KDBG=0
by Sylvain Petreolle 23 Apr '05

23 Apr '05

Trying to compile ros trunk with config set to DBG=1 and KDBG=0, I get the following errors into ntoskrnl. Can someone help ? ke/i386/exp.o: In function `KeRosPrintAddress': /mnt/hdb5/reactos/reactos/ntoskrnl/ke/i386/exp.c:113: undefined reference to `_KdbSymPrintAddress' ex/dbgctrl.o: In function `NtSystemDebugControl': /mnt/hdb5/reactos/reactos/ntoskrnl/ex/dbgctrl.c:38: undefined reference to `_KdbSymLoadUserModuleSymbols' io/driver.o: In function `IoDestroyDriverList': /mnt/hdb5/reactos/reactos/ntoskrnl/io/driver.c:(.text+0x568): undefined reference to `_KdbSymProcessBootSymbols' io/driver.o: In function `IopInitializeBootDrivers': /mnt/hdb5/reactos/reactos/ntoskrnl/io/driver.c:1262: undefined reference to `_KdbSymProcessBootSymbols' io/driver.o: In function `IopInitializeBuiltinDriver': /mnt/hdb5/reactos/reactos/ntoskrnl/io/driver.c:(init+0x67c): undefined reference to `_KdbSymProcessBootSymbols' ldr/loader.o: In function `LdrUnloadModule': /mnt/hdb5/reactos/reactos/ntoskrnl/ldr/loader.c:404: undefined reference to `_KdbSymUnloadDriverSymbols' ldr/loader.o: In function `LdrLoadModule': /mnt/hdb5/reactos/reactos/ntoskrnl/ldr/loader.c:387: undefined reference to `_KdbSymLoadDriverSymbols' ldr/loader.o: In function `LdrUnloadModule': /mnt/hdb5/reactos/reactos/ntoskrnl/ldr/loader.c:422: undefined reference to `_KdbSymInit' Kind regards, Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

1 0

14725 breaks the bootcd and livecd
by WaxDragon 23 Apr '05

23 Apr '05

After these changes, both the livecd and bootcd hang qemu and cause vmware to stack fault and reboot. WD -- "<tinus_> and also win32k should be fixed up a bit"

4 5

thread lists
by Hartmut Birr 23 Apr '05

23 Apr '05

Hi, our current thread and process structures have two thread lists, one in KPROCESS/KTHREAD and another in EPROCESS/ETHREAD. Do we need both lists? - Hartmut

2 1

Re: [ros-svn] [hpoussin] 14749: Add Green driver, that emulates a VT100 compatible server.
by Alex Ionescu 23 Apr '05

23 Apr '05

hpoussin(a)svn.reactos.com wrote: >Add Green driver, that emulates a VT100 compatible server. >Input won't work as long as we don't have a kdbclass driver. > > > > Why don't you commit tinus' I8042PRT? Best regards, Alex Ionescu

2 1

Freeldr changes
by Ge van Geldorp 22 Apr '05

22 Apr '05

Art, The freeldr changes I just checked in more or less formalize the concepts of a boot volume/partition (containing freeldr.sys and freeldr.ini) and a system volume/partition (containing \ReactOS). Most of the time, the boot volume and system volume will be the same, but it's not required. The main freeldr code no longer knows anything about partitions, this is handled in the architecture-dependent functions now. The main code is given an opaque drive number and the sector number at which a partition/slice/volume starts. There are a number of new Mach functions: BOOL MachDiskGetBootVolume(PULONG DriveNumber, PULONGLONG StartSector, PULONGLONG SectorCount, int *FsType) which should return the boot DriveNumber (the main freeldr code just hands it back to MachDiskReadLogicalSectors when needed), the StartSector of the boot partition/slice/whatever, the SectorCount of the boot partition/slice/whatever and the FsType (FS_FAT, FS_EXT2 etc.). The i386 MachDiskGetBootVolume() uses the boot drive and boot partition passed in by the BIOS/boot sector to set the values, but the ppc implementation is ofcourse free to handle it in its own way. BOOL MachDiskGetSystemVolume(char *SystemPath, char *RemainingPath, PULONG Device, PULONG DriveNumber, PULONGLONG StartSector, PULONGLONG SectorCount, int *FsType) This routine takes a SystemPath, which for i386 is something like multi(0)disk(0)rdisk(0)partition(1)\ReactOS and finds the DriveNumber, StartSector, SectorCount and FsType from that. If RemainingPath is non-NULL, in this example it will return \ReactOS in it. Device can be NULL, if it's not the value appropriate for LoaderBlock.BootDevice will be returned there. The format of the SystemPath passed in is architecture-dependent. It's taken from freeldr.ini and passed on to MachDiskGetSystemVolume() by the main freeldr code without any attempt to interpret it. BOOL MachDiskGetBootPath(char *BootPath, unsigned Size) This constructs a system path for the boot volume. The i386 routine does this by referencing its internal i386BootDrive and i386BootPartition variables. VOID MachDiskGetBootDevice(PULONG BootDevice) Returns a suitable value for LoaderBlock.BootDevice for the boot volume. BOOL MachDiskBootingFromFloppy() Returns TRUE when booting from a low-capacity device. Gé van Geldorp.

2 1

Re: [ros-svn] [ion] 14742: Thread Creation and Context Switching re-write, plus Idle/First Thread minimization attempt. Full changelog on ML, too large to post here
by Alex Ionescu 22 Apr '05

22 Apr '05

ion(a)svn.reactos.com wrote: >Thread Creation and Context Switching re-write, plus Idle/First Thread minimization attempt. Full changelog on ML, too large to post here > > Main Differences in new Task Swithcer: - All written in Intel Syntax - Single file and function handles both cases of System and User thread switching and contexts. - Starting Frame creation during Thread Context Creation is now structure-based instead of a stack array. Cleaner to read and more explicative. - ExceptionList is properly set to -1 when needed. This should make PSEH 2 work. - Context switch routine now has ALL registers available to it, including EBP. - Context switch routine uses access to KPCR through a register, improving speed. - KPCR Stack Data properly updated during context switch. - KTSS CR3 properly updated during context switch. - LDT, CR3 and IOPM are only updated if the new thread's process is different, increasing speed for the simple path. - The LDT and TEB Selectors are written directly in the GDT, bypassing a complicated STDCALL routine which messed up registers and was slow. - Kthread.ContextSwitches is properly incremented now. - Kthread.State is properly set to Running now. The three goals were Speed, Clarity, Completeness. Other Differences: - Threads used to start either in PsBeginThread or PsBeginThreadWithContext. PsBeginThread would lower to passive and call the start routine with the start context, then terminate. PsBeginThreadWithContext also lowered irql, but then restored debug registers and used KiServiceExit to go to user-mode. A new function now exists called KiThreadStartup, based on NT's implementation (see Inside Windows 2000). It lowers IRQL to APC_LEVEL and then calls the System Routine, which is on the stack with the two parameters (StartRoutine and STartcontext). This System Routine ressembles PsBeginThread/PsBeginThreadWithContext. Depending on how the thread was created, it can either by PspSystemThreadStartup, which lowers IRQL to passive and then calls the StartRoutine. Or, it can be PspUserThreadStartup, which queues the User-Mode APC and inserts it, then lowers IRQL to passive and notifies the Debugger. Notice that the APC is now queued here, much later then before. After that, we return to KiThreadStartup, which will bugcheck if the system thread returned (it shouldn't), or will use KiServiceExit2, which does the same as the old ros, which is to restore the debug registers. IT then immediately does an IRET after cleaning the trap frame. Calling KiServiceExit is not correct because it might end up using SYSEXIT when clearly we weren't SYSENTERED. - Idle thread, first thread, first process and idle process are concepts which ROS gets really wrong. I have a patch which fixes these issues, but it is still heavily under testing. Until then, this patch also includes some changes which make the Idle/First Thread much less heavy, and are simple blocks of memory with the minimum amount of data possible to have a working system. They are not objects anymore, nor should they be. This isn't the final implementation but ressembles it and lays the minimal groundwork. - I will make a shorter patch-fix which will make Ki386InitializeThreadWithContext use the KeContextToTrapFrame function and complete it as well, in order to use only the fields which were specified by the caller. Best regards, Alex Ionescu

1 1

Re: [ros-svn] [fireball] 14730: Added xbox video driver information (by GvG), I hope it doesn't interfere anyone, and there will be no need to patch registry everytime to boot under xbox.
by Gge 22 Apr '05

22 Apr '05

fireball(a)svn.reactos.com wrote: > Added xbox video driver information (by GvG), I hope it doesn't interfere anyone, and there will be no need to patch registry everytime to boot under xbox. > > > Updated files: > trunk/reactos/bootdata/hivesys.inf > Is it possible to add also the nic realtek8139 and nvidia display driver informations as well for the same need ? Regards Gerard

1 0

RE: [ros-dev] 7-zip - holy smokes!
by Waldo Alvarez Cañizares 21 Apr '05

21 Apr '05

Hi: I doubt normal Windows users will be downloading sources of anything ever. BTW is a lot more dificult to set the build environment than to decompress the sources using 7zip. Beleiveme is a real pain to download ROS if you have a dialup connection. Why waste our time when we don't need to. Again if still you consider that a zip distribution should still be available for download why not distribute both zip and 7zip. Is that much space? Or it takes to much time to pack? I would answer no to both questions. Regards Waldo -----Original Message----- From: ros-dev-bounces(a)reactos.com on behalf of Andrew Flynn Sent: Thu 4/14/2005 4:28 AM To: ReactOS Development List Subject: Re: [ros-dev] 7-zip - holy smokes! I agree with Michael B. 7Zip is superior to ZIP. You have to remember who will be downloading the source, compressed files. Is it going to be standard windows users that use winzip and nothing else? When it comes to mass distribution of images, the iso format seems like a sensible choice, where the setup programs can utilise whatever compression they like. PKZip may be the most popular, but that does not mean that ReactOS files have to use it. Michael B. Trausch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: RIPEMD160 > >Thomas Weidenmueller wrote: > > >>I don't think it's a good choice for our public downloads, the avarage >>user most likely will not know this format. zip still is THE standard. >> >> >> > >True, it is. However, end-users will follow whatever trends are set for >them. ZIP got to be big and well-known because of PKZip, honestly. > >If 7-Zip is that much better, then I'd say we go for it and put in >something like red text above the link to the downloads page that we use >7-Zip. > >Or, we could give users their option and offer both. Those concerned >about bandwidth would use the 7-Zip version, and those who don't care >can go with the other one. > >As far as users and .EXE files - End Users download EXE files all of the >time. They don't know any better. They see the box in MSIE and go, >"Yeah, whatever, it's my computer and I wanna download it," click it >away and move on. *shrugs* > >That's why I make money outside of my job, cleaning up after people's >idiotic mistakes, but that's another story altogether. If we offer them >a self-extracting version and a 7-Zip'd version, that'd be even better >in terms of download time/bandwidth. > >Not to mention, if 7-Zip can be distributed with ReactOS, it's a good >way to get it out there. Since it's under LGPL, it'd be something that >could even be built into ReactOS in the same way as .ZIP format support >is built into more recent versions of Windows (and hopefully, just as >easy to disable, because I hate that feature, but plenty of people >absolutely love it). > >Not only all of that, but since it's a superior compression scheme, it'd >be logical to support it and help further it's distribution so that >people would use it. People don't just sit down very frequently and go, >"Hrm. I think I am going to search out a new way to compress my files," >because they figure that compression is compression is compression, and >that's all there is to it. > >All in all, I think it'd be wise, especially over the long-term, to use >and support 7-Zip. > > - Mike > >- -- >Michael B. Trausch <fd0man(a)gmail.com> >Website: http://fd0man.chadeux.net/ Jabber: mtrausch(a)jabber.com >Phone: +1-(678)-522-7934 FAX (US Only): 1-866-806-4647 >=================================================================== >Do you have PGP or GPG? Key at pgp.mit.edu, Please Encrypt E-Mail! > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.1 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFCXcHQPXInbkqM7nwRA4D1AJ93vO8bTantG9QSWgtejVN0CotNiQCfe1rM >z6njCB0ucQYWNIAoofS9bD8= >=d5Zf >-----END PGP SIGNATURE----- >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-dev > > > > _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

7 6

ReactOS Banner
by Jason Filby 19 Apr '05

19 Apr '05

Hi all I remember someone removed the 'User Site' from the ReactOS banner on our current site. Can that someone please send me the image, it seems people would like to see it on the new site design. Thanks Jason

2 1

problems about ros-diffs and viewcvs
by d_layer 19 Apr '05

19 Apr '05

Hello, Currently I'm experiencing two problems. Is there any plan to fix them? 1. ros-diffs list no longer delivers HTML mails. (since revision 14639) 2. Accessing to http://svn.reactos.com/viewcvs/ now requires an authentication. (I don't know exact date of occurrence) Thanks, -- d_layer

2 1

Broken!
by James Tabor 19 Apr '05

19 Apr '05

Hi, (NTDLL:ldr/utils.c:2039) Failed to create or open dll section of '\??\C:\ReactOS \system32\csrss.exe' (Status c0000135) Unhandled exception Address: 7c924078 C:\ReactOS\system32\ntdll.dll CS:EIP 1b:7c924078 DS 23 ES 23 FS 3b GS 23 EAX: 00a08139 EBX: 008f6500 ECX: 00000004 EDX: 00007269 EBP: 0055d96c ESI: 77a94000 ESP: 0055d964 EDI: 00a08139 EFLAGS: 00010202 Frames: 77a90000+1454 C:\ReactOS\system32\VERSION.dll 77a90000+148d C:\ReactOS\system32\VERSION.dll 400000+115d C:\ReactOS\tools\listdlls.EXE (toolbar.c:411:TOOLBAR_GetImageListForDrawing) bitmap for ID 0, index 1 is not v alid, number of bitmaps in imagelist: 0 (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 750000) C:\ReactOS\system32\gdi 32.dll (rpcrt4_main.c:156:DllMain) Failed to create master mutex (ps/cid.c:119) CID Obj type mismatch handle 0x4 Thread vs 0x1 mm/mm.c:338 Unhandled exception Address: 4018bf C:\ReactOS\bin\ps.EXE CS:EIP 1b:4018bf DS 23 ES 23 FS 3b GS 23 EAX: 00651aa0 EBX: 0042e000 ECX: 00651938 EDX: 00651b8c EBP: 0064ff88 ESI: 00000000 ESP: 0064fcd0 EDI: 0064fd1e EFLAGS: 00010216 Frames: 400000+11e7 C:\ReactOS\bin\ps.EXE 400000+1238 C:\ReactOS\bin\ps.EXE 7c800000+2876f C:\ReactOS\system32\kernel32.dll Listdll and ps both work with XP so??? What is wrong with ROS? James

2 1

RosApps CTM Broken
by James Tabor 19 Apr '05

19 Apr '05

Hi, Need to check this one too. make[1]: Entering directory `/home/ros/rosapps/sysutils/ctm' ctm: [CC] ctm.c ctm.c: In function `PerfDataRefresh': ctm.c:356: error: `PSYSTEM_PROCESSES' undeclared (first use in this function) ctm.c:356: error: (Each undeclared identifier is reported only once ctm.c:356: error: for each function it appears in.) ctm.c:356: error: syntax error before "pSPI" ctm.c:361: error: `PSYSTEM_PROCESSORTIME_INFO' undeclared (first use in this function) ctm.c:361: error: syntax error before "SysProcessorTimeInfo" ctm.c:377: error: `SysProcessorTimeInfo' undeclared (first use in this function) ctm.c:377: error: syntax error before "malloc" ctm.c:378: error: `SYSTEM_PROCESSORTIME_INFO' undeclared (first use in this function) ctm.c:382: error: syntax error before ')' token ctm.c:419: error: `pSPI' undeclared (first use in this function) ctm.c:419: error: syntax error before "pBuffer" ctm.c:431: error: syntax error before "pBuffer" make[1]: *** [ctm.o] Error 1 make[1]: Leaving directory `/home/ros/rosapps/sysutils/ctm' James

1 0

Re: [ros-svn] [navaraf] 14686: Reenable ControlService and fix syntax errors in svcctl.idl.
by Thomas Weidenmueller 18 Apr '05

18 Apr '05

navaraf(a)svn.reactos.com wrote: > Reenable ControlService and fix syntax errors in svcctl.idl. That fixes the problems, thanks. Thomas

1 0

Re: [ros-svn] [navaraf] 14686: Reenable ControlService and fix syntax errors in svcctl.idl.
by James Tabor 18 Apr '05

18 Apr '05

Hi! navaraf(a)svn.reactos.com wrote: > Reenable ControlService and fix syntax errors in svcctl.idl. > > > Updated files: > trunk/reactos/include/idl/svcctl.idl > trunk/reactos/lib/advapi32/service/scm.c > trunk/reactos/subsys/system/services/rpcserver.c > advapi32: [DEPENDS] token/.token.d advapi32: [DEPENDS] token/.privilege.d advapi32: [DEPENDS] service/.undoc.d advapi32: [DEPENDS] service/.sctrl.d advapi32: [DEPENDS] service/.scm.d service/scm.c:16:22: svcctl_c.h: No such file or directory advapi32: [DEPENDS] service/.eventlog.d ../../include/idl/svcctl.idl:17: Error: syntax error make[1]: *** [service/svcctl_c.c] Error 1 At revision 14686. James

1 0

Re: [ros-svn] [ekohl] 14656: Support out-pointers to structs.
by Thomas Weidenmueller 18 Apr '05

18 Apr '05

ekohl(a)svn.reactos.com wrote: > Support out-pointers to structs. > > > Updated files: > trunk/reactos/tools/widl/ChangeLog > trunk/reactos/tools/widl/server.c I believe these changes causes a crash when trying to compile subsys/system/services: gcc -Wall -Werror -fno-builtin -D__USE_W32API -D_WIN32_IE=0x0500 -D_WIN32_WINNT= 0x501 -DWINVER=0x600 -DUNICODE -D_UNICODE -I. -O2 -Wno-strict-aliasing -I../../. ./include -I../../../w32api/include -pipe -march=i486 -D_M_IX86 -g -M rpcserver. c | ..\..\..\tools\depends.exe . .rpcserver.d rpcserver.c:13:22: svcctl_s.h: No such file or directory gcc -Wall -Werror -fno-builtin -D__USE_W32API -D_WIN32_IE=0x0500 -D_WIN32_WINNT= 0x501 -DWINVER=0x600 -DUNICODE -D_UNICODE -I. -O2 -Wno-strict-aliasing -I../../. ./include -I../../../w32api/include -pipe -march=i486 -D_M_IX86 -g -M services.c | ..\..\..\tools\depends.exe . .services.d gcc -Wall -Werror -fno-builtin -D__USE_W32API -D_WIN32_IE=0x0500 -D_WIN32_WINNT= 0x501 -DWINVER=0x600 -DUNICODE -D_UNICODE -I. -O2 -Wno-strict-aliasing -I../../. ./include -I../../../w32api/include -pipe -march=i486 -D_M_IX86 -g -M database.c | ..\..\..\tools\depends.exe . .database.d ../../../tools/widl/widl -o -h -H svcctl_s.h -s -S svcctl_s.c ../../../include/i dl/svcctl.idl ../../../include/idl/svcctl.idl:124: Oops, segment violation This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. make: *** [svcctl_s.c] Error 3

5 7

RE: [ros-dev] new keyboard layout
by Roman Hoegg 18 Apr '05

18 Apr '05

1 0

Re: Comment on ROS
by Jason Filby 18 Apr '05

18 Apr '05

Thanks Martin! On 4/17/05, J.S. Martin <josmar52789(a)gmail.com> wrote: > I think you guys are doing a great job with ReactOS. I tried it out > about a year ago and I thought it was OK, not useful to my needs, but > a good effort. Then I tried it out yesterday and I was absolutely > amazed! If you guys keep trying and keep making progress, you will > certainly make this a great OS and I will definitely be willing to use > it all the time. Keep up the great work! > -- > J.S. Martin >

1 0

Listdlls util.
by James Tabor 18 Apr '05

18 Apr '05

WARNING: This e-mail has been altered by MIMEDefang. Following this paragraph are indications of the actual changes made. For more information about your site's MIMEDefang policy, contact MIMEDefang Administrator <postmaster(a)deos.tudelft.nl>. For more information about MIMEDefang, see: http://www.roaringpenguin.com/mimedefang/enduser.php3 An attachment named listdlls.exe was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. Hi, Here is list dlls utility, James

2 3

new keyboard layout
by Roman Hoegg 18 Apr '05

18 Apr '05

Hello everybody, I've uploaded a "patch" to bugzilla that adds support for Swiss German keyboards (kbdsg.dll) to ReactOS. http://www.reactos.com/bugzilla/show_bug.cgi?id=509 (The zip-file I uploaded contains the content of .../lib/kbdsg) I've tested it on qemu and on real hardware and as far as I can tell it works great. It would be great if it were included into the official ReactOS sources. If you need any further information (or files) please let me know. kind regards Roman Hoegg roman.hoegg(a)unisg.ch romanh(a)unisg.ch P.S. I'm sorry if you have received this email twice. I tried to send this information to the mailinglist yesterday but it didn't seem to get through. ------------------------------------------ Roman Högg Research Assistant =mcm institute for Media and Communications Management University of St. Gallen, Switzerland Blumenbergplatz 9, 9000 St. Gallen Phone +41 (0)71 224 34 39 Mobile +41 (0)79 418 59 13 e-mail roman.hoegg(a)unisg.ch http://www.mcm.unisg.ch

3 2

Problem building gdi32
by Mike Lerwill 17 Apr '05

17 Apr '05

Hi, I am experiencing problems building current source as follows gdi32: [LD] gdi32.nostrip.dll objects/brush.o(.text+0x52): In function `CreateDIBPatternBrush': I:/reactos/lib/gdi32/objects/brush.c:41: undefined reference to `NtGdiCreateDIBBrush@16' objects/brush.o(.text+0xc7): In function `CreateDIBPatternBrushPt': I:/reactos/lib/gdi32/objects/brush.c:71: undefined reference to `NtGdiCreateDIBBrush@16' collect2: ld returned 1 exit status make[1]: *** [gdi32.nostrip.dll] Error 1 make: *** [gdi32] Error 2 I have made sure I am fully current with the source and have tried a full "clean" but to no avail. Can anyone throw some light onto this problem. Mike Lerwill

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev