Ros-dev

ros-dev@reactos.org

5790 discussions

Start a nNew thread

Re: [ros-dev] Patch up for testing
by Filip Navara 16 Jun '05

16 Jun '05

1 0

lib/crt/stdlib/strtoull.c buggy?
by Mark Junker 16 Jun '05

16 Jun '05

Hi, the strtoull function should work with "long long"s instead of "long"s. A patch is attached. However, it would be better to test for the existence of a 64 bit integral data type and compile this function optionally ... BTW: It seems that all sources in lib/crtdll/ (except dllmain.c and precomp.h) are unused. Is this correct? Regards, Mark Index: lib/crt/stdlib/strtoull.c =================================================================== --- lib/crt/stdlib/strtoull.c (revision 15932) +++ lib/crt/stdlib/strtoull.c (working copy) @@ -4,21 +4,49 @@ #include <ctype.h> #include <errno.h> #include <stdlib.h> -//#include <msvcrt/unconst.h> +/* #include <msvcrt/unconst.h> */ +/* required to get prototype for __set_errno() */ +#include <internal/file.h> + +#if defined(LONG_LONG_MAX) +/* GCC-style constant */ +#define ROS_LLONG_MAX LONG_LONG_MAX +#define ROS_ULLONG_MAX ULONG_LONG_MAX +typedef long long ros_ll; +typedef unsigned long long ros_ull; +#elif defined(_I64_MAX) +/* MSVC-style constant */ +#define ROS_LLONG_MAX _I64_MAX +#define ROS_ULLONG_MAX _UI64_MAX +typedef __int64 ros_ll; +typedef unsigned __int64 ros_ull; +#elif defined(LLONG_MAX) +/* C9x-style constant */ +#define ROS_LLONG_MAX LLONG_MAX +#define ROS_ULLONG_MAX ULLONG_MAX +#include <stdint.h> +typedef int64_t ros_ll; +typedef uint64_t ros_ull; +#else +#define ROS_LLONG_MAX LONG_MAX +#define ROS_ULLONG_MAX ULONG_MAX +typedef long ros_ll; +typedef unsigned long ros_ull; +#endif + /* * Convert a string to an unsigned long integer. * * Ignores `locale' stuff. Assumes that the upper and lower case * alphabets and digits are each contiguous. */ -unsigned long +ros_ull strtoull(const char *nptr, char **endptr, int base) { const char *s = nptr; - unsigned long acc; + ros_ull acc, cutoff; int c; - unsigned long cutoff; int neg = 0, any, cutlim; /* @@ -43,8 +71,8 @@ } if (base == 0) base = c == '0' ? 8 : 10; - cutoff = (unsigned long)ULONG_MAX / base; - cutlim = (unsigned long)ULONG_MAX % base; + cutoff = (ros_ull)ROS_ULLONG_MAX / base; + cutlim = (int) ((ros_ull)ROS_ULLONG_MAX % base); for (acc = 0, any = 0;; c = *s++) { if (isdigit(c)) @@ -65,7 +93,7 @@ } if (any < 0) { - acc = ULONG_MAX; + acc = ROS_ULLONG_MAX; __set_errno ( ERANGE ); } else if (neg)

1 0

rbuild issue
by Hartmut Birr 15 Jun '05

15 Jun '05

Hi, our new build system doesn't use the assembler string functions in lib\string. - Hartmut

2 1

Re: [ros-svn] [ion] 14754: Add KDBG debugging hack from old code and convert it to fit new one. Not enabled yet because it underflows the stack after a while (researching why).
by Anich Gregor 13 Jun '05

13 Jun '05

This breaks parts of KDB too. Please finish your changes to ctxswitch.S and put back the old functionality (which KDB relies on) if possible.

2 2

Re: [ros-svn] [ion] 14790: Don't use hack for trap frames anymore, read TempEsp and TempSegSs for kernel-mode traps during debugging.
by Anich Gregor 13 Jun '05

13 Jun '05

Please revert these changes if possible, they are part of KDBs current breakage and pretty much incorrect (from KDBs point of view)

2 2

crash in win32k with the cirrus driver
by Hartmut Birr 13 Jun '05

13 Jun '05

Hi, if I use the cirrus driver in qemu, I get always wrong colors. After the first double click to the cmd icon, ros crashs in DIB_16BPP_BitBltSrcCopy. I've add the following code: Index: subsys/win32k/dib/dib16bpp.c =================================================================== --- subsys/win32k/dib/dib16bpp.c (Revision 15885) +++ subsys/win32k/dib/dib16bpp.c (Arbeitskopie) @@ -228,6 +228,8 @@ } else { + DPRINT1("%d %d %d\n", BltInfo->SourceSurface->lDelta, BltInfo->SourcePoint.x, BltInfo->SourcePoint.y); + DPRINT1("%d %d %d %d %d\n", BltInfo->DestSurface->lDelta, BltInfo->DestRect.left, BltInfo->DestRect.top, BltInfo->DestRect.right, BltInfo->DestRect.bottom); I see often negative values for the source surface: ... (subsys\win32k\dib\dib16bpp.c:231) -1120 -69 -69 (subsys\win32k\dib\dib16bpp.c:232) 1600 0 0 0 0 (subsys\win32k\dib\dib16bpp.c:231) -1120 -69 -69 (subsys\win32k\dib\dib16bpp.c:232) 1600 0 0 0 0 (subsys\win32k\dib\dib16bpp.c:231) -1120 0 13 (subsys\win32k\dib\dib16bpp.c:232) 1600 69 69 629 87 KeBugCheckWithTf at ntoskrnl\ke\catch.c:222 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. ... I seems that win32k doesn't handle the negative values. I doesn't know what they mean. - Hartmut

3 4

RE: [ros-dev] Visual IDE for ROS
by Murphy, Ged (Bolton) 13 Jun '05

13 Jun '05

Joseph Miller wrote: > So I am currently working on making my Visual GWin++ > project work under ReactOS. If it works under windows, it should work under ROS. If it doesn't, it's likely there is some missing functionality or bugs in ROS at the moment. You shouldn't modify your program to work under ROS if it breaks Windows functionality, as it's likely to be fixed in the future. If it works under Windows but not ROS, try to establish why and report it. This would be a more productive way for both projects. Regards, Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

3 2

RE: [greatlrd] 15881: revert back to 15869 for current changebreak 32 / 8 bpp for vbe drv, and vmware drv the mouse did not redaw some dialog box was wrong. andalot more
by Ge van Geldorp 13 Jun '05

13 Jun '05

> revert back to 15869 for current change break 32 / 8 bpp for > vbe drv, and vmware drv the mouse did not redaw some dialog > box was wrong. and alot more Can you show me how to reproduce the problems. It seems to work fine for me in VMware with 8/16/32 bpp and in Qemu with 8/16/24 bpp (all with VBE driver). Gé van Geldorp.

1 0

[Fwd: Re: [ros-diffs] [greatlrd] 15879: fix bug in color fill inline asm code. Did crash cirrus drv, vmware 5 drv and if the buffer was not align. Clean up inline asm code.]
by Hartmut Birr 13 Jun '05

13 Jun '05

-------- Original Message -------- Subject: Re: [ros-diffs] [greatlrd] 15879: fix bug in color fill inline asm code. Did crash cirrus drv, vmware 5 drv and if the buffer was not align. Clean up inline asm code. Date: Sun, 12 Jun 2005 22:44:48 +0200 From: Hartmut Birr <hartmut.birr(a)gmx.de> Reply-To: ReactOS Diffs List <ros-diffs(a)reactos.com> To: ReactOS Diffs List <ros-diffs(a)reactos.com> References: <000001c56f84$4a6757a0$6b01a8c0@PENELOPE> greatlrd(a)svn.reactos.com wrote: >fix bug in color fill inline asm code. Did crash cirrus drv, vmware 5 drv and if the buffer was not align. Clean up inline asm code. > >Modified: trunk/reactos/subsys/win32k/dib/dib16bpp.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/subsys/win32k/dib/dib16bpp.c* > >--- trunk/reactos/subsys/win32k/dib/dib16bpp.c 2005-06-12 19:06:38 UTC (rev 15878) >+++ trunk/reactos/subsys/win32k/dib/dib16bpp.c 2005-06-12 19:23:40 UTC (rev 15879) > >@@ -454,31 +436,34 @@ > > > ULONG delta = DestSurface->lDelta; > ULONG width = (DestRect->right - DestRect->left) ; > PULONG pos = (PULONG) (DestSurface->pvScan0 + DestRect->top * delta + (DestRect->left<<1)); > > >- color = (color<<16)|(color&0xffff); /* If the color value is "abcd", put "abcdabcd" into color */ > > >+ color = (color&0xffff); /* If the color value is "abcd", put "abcdabcd" into color */ >+ color += (color<<16); > > > > for (DestY = DestRect->top; DestY< DestRect->bottom; DestY++) > > >- { >- int d0, d1, d2; > > >+ { > > > __asm__ __volatile__ ( > " cld\n" > > >+ " mov %0,%%eax\n" >+ " mov %1,%%ebx\n" > > > " test $0x03, %%edi\n" /* Align to fullword boundary */ > " jz .FL1\n" > " stosw\n" > > >- " dec %4\n" > > >+ " dec %%ebx\n" > > > " jz .FL2\n" > ".FL1:\n" > > >- " mov %4,%%ecx\n" /* Setup count of fullwords to fill */ > > >+ " mov %%ebx,%%ecx\n" /* Setup count of fullwords to fill */ > > > " shr $1,%%ecx\n" > " rep stosl\n" /* The actual fill */ > > >- " test $0x01, %4\n" /* One left to do at the right side? */ > > >+ " test $0x01, %%ebx\n" /* One left to do at the right side? */ > > > " jz .FL2\n" > " stosw\n" > ".FL2:\n" > > >- : "=&A" (d0), "=&r" (d1), "=&D" (d2) >- : "0"(color), "1"(width), "2"(pos) >- : "%ecx"); > > >+ : >+ : "r" (color), "r" (width), "D" (pos) >+ : "%eax", "%ecx","%ebx"); > > > pos =(PULONG)((ULONG_PTR)pos + delta); > } > > >+ > > > #else /* _M_IX86 */ > > for (DestY = DestRect->top; DestY< DestRect->bottom; DestY++) > > What was wrong with the inline code from rev 15869? Previous my changes (rev 15858), the width value was only load in the first loop. This has crashed the vbe driver on real hardware. I've no problems with the current and the last revision, and with normal and optimized builds. The only difference is, that your changes needs two registers more on optimized builds and gcc uses the stack to store some values. There exist one problem in your changes, gcc doesn't know that edi is changed. On other optimisation as the current one, it is possible that gcc uses edi to recalculate the pos value. With optimized build, I mean the optimisation, if DBG is 0. - Hartmut

1 0

Visual IDE for ROS
by Joseph Miller 12 Jun '05

12 Jun '05

Hello list, I am new to ReactOS, but very interested in Win32 programming. I am also very new to Win32 and C++, but I began a project about a year ago to develop and open source Visual C++ IDE for Win32 because I had not found an open source one yet. Well, it was one of my first attempts at Win32 and at C++, but I managed to create a very basic IDE and I have successfully created several programs for both work and other projects. Everything is based on a class called GWin. I feel like the GWin code is very stable, even at this point, but much of the API will probably still change as I learn about Win32. Unfortunately, the IDE code is pretty dang crappy because I did not understand some very basic programming concepts. To make a long story short, the IDE has been developed to a usable point, and the code in the GWin class is worth continuing. The IDE itself is undergoing a major rewrite for better functionality and structure. Yesterday I installed ReactOS for the very first time on my computer. I was impressed with the number of programs that actually work at this stage of development. Even Scite (an excellent, code-highlighting editor) works! So I am currently working on making my Visual GWin++ project work under ReactOS. I have managed to get it running and compile a test program under ReactOS, so with a little more testing, I will release a version just for ROS. I will also be working on a tutorial for how to get started with it. Visual GWin++ currently has support for windows, edit controls, static controls, listbox controls, MDI clients (limited), tabcontrols, and scrollbars (limited). The program can load and save projects in an XML file format using libxml. The current version is v0.02-pre-alpha. You can see the Windows version at http://www.calcmaster.net/visual-c++/ . When the ROS version is ready, I will release it. I would like some feedback on what you guys think about this project and whether or not you think it will be a benefit to ROS. BTW, I came across some message handling bugs in ROS and I guess this is the mailing list to report it? I will try to download the source and look it over, but I wanted to let you guys know first. I had a handler set up for EN_KILLFOCUS on one of my edit controls. The function was supposed to modify another window and then return. I'm assuming what happened was that as my function was modifying the other window, ROS kept assuming that it needed to send more EN_KILLFOCUS messages to me to let me know my control had lost focus. I had to add a hack to make sure that after the handler is called the first time, it is not called again until it has completed what it needs to do. I had a similar problem with LBN_SELCHANGE when I tried to kill the control's parent window. ROS assumed that this meant it needed to tell me that the selection had changed and sent LBN_SELCHANGE. This caused the same type of loop that I described above. Where do I look to correct this? -Joseph

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev