Re: RtlAtom tests improved
I figured out that the RtlCreateAtomTable function as expecting to get passed in a NULL as the initial Table, otherwise it thinks that the argument is a valid atom table and just returns success. This unfourtuneatly makes the test results that Dimitrie send useless because RtlCreateAtomTable thought I realy did mean Dimitry. that the table was valid but all the other functions realised that it wasn't. Could someone please rerun these tests on an nt system again? ChangeLog: * dlls/ntdll/tests/Makefile.in * dlls/ntdll/tests/atom.c Add tests for RtlAtom functions. nog.
Re: RtlAtom tests further improved
Looking at the ReactOS implementations of RtlAtom* APIs, I've found that they conform to the results I get under win2k. Did you try to ask a permission to use their implementation in Wine? Steven? I don't think that shall be necessary, it looks like all that support is in the wineserver already. It seems like all that is required is to add a couple of server calls, but I may be wrong. nog.
Re: d3d three more renderstates for n2002
with one of the last patches from the cvs the game Nascar 2002 now recognizes the d3d rasterizer in the config tool. The patch below adds three more handlers for the D3DRENDERSTATE. As d3d seems to me pretty undocumented i can only try to find things out using goolgle and see the example code there - a link to doku would be really appreciated. For the documentation, do a Google search on the .CHM files from the various DirectX SDKs (as the relevant documentations are not to be found anymore on MSDN's site, only DX8 / 9 is still there). Im not sure if your refering to the online documentation (if you are then your right), but at least the dx7a sdk is still availible from: http://download.microsoft.com/download/win98SE/DXSDK/7.0a/W9X/EN-US/dx7adxf.exe nog.
Re: Where to use dosdev
Should we also use the functions in the devices.c to implement all functions on devices like ioctls etc.? for the other int21 (disk read/write for instance), yes ioctl are the way to go I don't quite understand your english here, are you saying that ioctls in int21 _should_ be implemented using functions from devices.c (like DOSDEV_IoctlRead/DOSDEV_IoctlWrite)? nog.
Where to use dosdev
In some of the int21 routines it says that we should use DOSDEV_Peek/Read/Write. Should we also use the functions in the devices.c to implement all functions on devices like ioctls etc.? nog.
DPMI_CallRMProc trouble
I realy need help with this. Whenever I call a DOSDEV_ function then that function eventually calls DOSDEV_DoReq. This function calls DPMI_CallRMProc. Now that function call DOSMEM_GetBlock( 64, (UINT16 *)(context-SegSs) ) to try and allocate a stack. This fails for some reason but I dont understand why because it succeds if called from int21/48. Anyone know whats going on? nog.
Re: dosconf move
György 'Nog' Jeney [EMAIL PROTECTED] writes: Is there any reason why this patch has not been applied? This is essentially the same as my dosconf try 3 patch but for your convinience I made a new diff against the current cvs. It's really ugly to export the DOSCONF structure as part of the DOS module interface. I think it's better to wait until that stuff can be moved without having to export it. This uglyness doesnt haveto stay around for to long as this patch was to split up my patches a bit for my int21 move for which I have posted a patch already. Is there any reason why THAT one has not been applied? BTW Im very sorry for sending 3 e-mails but my squirelmail/internet connection just doesnt work well. I have to push the stop button on my browser to stop sending the mail over and over again. This time I got the timeing wrong as I was having a Voip conversation at the same time.
Re: _itoa
Folks, msvcrt has this in its spec file: dlls/msvcrt/msvcrt.spec:@ forward -noimport _itoa ntdll._itoa ^ This is your problem. This tell winebuild to not export this function to winelib apps. The reason for this is probably to make pepole use the native unix version. Why I dont know. Yet at link time, I get an undefined reference error: /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lmsvcrt gcc -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm project.o: In function `CProject::Open(char*, unsigned short)': project.o(.text+0x20e5): undefined reference to `_itoa' winui.o: In function `CStatusBar::WriteLong(long, int)': winui.o(.text+0x1d9a): undefined reference to `_itoa' winui.o: In function `CMessageBox::DisplayLong(long)': winui.o(.text+0x30a2): undefined reference to `_itoa' However, if I also link in ntdll, it works: /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lntdll -lmsvcrt gcc -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm [dimi@dimi src]$ In ntdll the export does not have the -noimport flag set so that is why it works Question is, is this correct? Do I need to link ntdll into the app as well? I wouldnt think so but Im not sure because whats the difference if people use it directly from ntdll or from msvcrt? nog.
Re: _itoa
Folks, msvcrt has this in its spec file: dlls/msvcrt/msvcrt.spec:@ forward -noimport _itoa ntdll._itoa ^ This is your problem. This tell winebuild to not export this function to winelib apps. The reason for this is probably to make pepole use the native unix version. Why I dont know. Yet at link time, I get an undefined reference error: /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lmsvcrt gcc -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm project.o: In function `CProject::Open(char*, unsigned short)': project.o(.text+0x20e5): undefined reference to `_itoa' winui.o: In function `CStatusBar::WriteLong(long, int)': winui.o(.text+0x1d9a): undefined reference to `_itoa' winui.o: In function `CMessageBox::DisplayLong(long)': winui.o(.text+0x30a2): undefined reference to `_itoa' However, if I also link in ntdll, it works: /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lntdll -lmsvcrt gcc -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm [dimi@dimi src]$ In ntdll the export does not have the -noimport flag set so that is why it works Question is, is this correct? Do I need to link ntdll into the app as well? I wouldnt think so but Im not sure because whats the difference if people use it directly from ntdll or from msvcrt? nog.
Re: rundll32 utility
Changelog: - added rundll32 utility Would it be possible to simply implement the 16-bit rundll from this code? I havnt actually looked at this or anything, just thinking nog.
Re: int21 move a0-a7
Patch a1 is wrong and must not be applied. Function 0x0c is really a recursive call and cannot be handled this way. Simple fix would be to call DOSVM_Int21Handler from function 0x0c handler after AH register has been modified (and lets add a detailed comment here this time so everybody understands what 0x0c really does...). Call me blind, but I fail to see how DOSCONF_config gets initialized after patch a2. Ill resubmit my series of patches tommorrow, with these things fixed. This set of patches break DOS3Call and calling INT21 using VXDs and DeviceIoControl. I have no idea how much these interfaces are used but I guess this will be fixed in a future patch? Yes, I plan to fix this after I have finished to move the int21 stuff to winedos. nog.
Re: dosconf move try 2
This reminds me that int21 handling is quite messy. Interrups call first DOSVM_Int21Handler and might be chained to Dos3Call. But, if you call Dos3Call directly, execution does not go through DOSVM_Int21Handler. This causes some code duplication and makes things like dosconf unnecessarily complicated. I was hoping that I could leave this stuff to its current state until I had cleaned up other interrupts. Simple solution would be to make Dos3Call load winedos.dll and call DOSVM_Int21Handler through function pointer, move all common code from old Dos3Call to DOSVM_Int21Handler and move code that is difficult to handle in winedos to INT_Int21Handler which would be chained to from DOSVM_Int21Handler when a few selected functions need to be emulated. But this requires lots of work because each int21 function must be separately evaluated in order to see how it must be emulated to properly support both Win16 and DOS; first step would probably just add check if(DOSVM_IsWin16()) to each DOSVM_Int21Handler function and chain to INT_Int21Handler if true. The whole reason that I want to move dosconf to winedos is to be able to move int 21 to winedos. I'll begin work on this shortly but I have a question first: What should we do about vwin32.vxd? This is meant to provide dos ioclt support and int 21. It does so at the moment by calling the handler directly. Shoud we export These handlers from winedos? nog.
RtlQueryTimeZoneInformation
Does anyone know anything about RtlQueryTimeZoneInformation? I would like to implement it... nog.
Re: What is a leap second
On Wednesday 30 October 2002 09:12, György 'Nog' Jeney wrote: György, could you check which other includes can be used if winternl.h is absent? Else youll probably have to wait for somebody which has it to compile your test. This is included in the latest platform SDK but it should also be defined in ntddk.h. Ok, could somene rather compile this test and send its results? It will be quite big... FWIW, RtlTimeToTimeFields() was not declared in the winternl.h included in the PSDK (August 2002) I downloaded and I didn't bother to d/l the DDK as well... I took the prototype from Wine's winternl.h instead, together with the declarations for CSHORT and TIME_FIELDS. Then bcc32 doesn't like inline in C code, so I just removed that; LARGE_INTEGER apparently has no field named s in the headers that came with C++ Builder, but s/RtlTime.s./RtlTime./g helped for this; finally I had to rename WinMain() to main() as I didn't find the command line switch to produce a Windows Console app :-) Also I loaded RtlTimeToTimeFields() from ntdll via GetProcAddress to avoid rebuilding the import library. Anyway, output attached. Thank you and Peter for compiling my test. This just shows that our implementation is 100% correct and that windows does ignore leap seconds. nog.
Re: What is a leap second
György, could you check which other includes can be used if winternl.h is absent? Else youll probably have to wait for somebody which has it to compile your test. This is included in the latest platform SDK but it should also be defined in ntddk.h. Ok, could somene rather compile this test and send its results? It will be quite big... nog. timetest.c Description: Binary data
Re: What is a leap second
with the following output on win2k. 9 0 10 0 9 10 This is weird, I would have expected to get an output like: 2002 10 27 8 9 10 with the followingo patch applied... nog. Index: dlls/ntdll/time.c === RCS file: /home/wine/wine/dlls/ntdll/time.c,v retrieving revision 1.20 diff -u -r1.20 time.c --- dlls/ntdll/time.c 12 Sep 2002 22:07:03 - 1.20 +++ dlls/ntdll/time.c 30 Oct 2002 13:06:12 - -89,7 +89,11 int LeapSecondCorrections, SecondsInDay, CurYear; int LeapYear, CurMonth, GMTOffset; long int Days; - LONGLONG Time = *(LONGLONG *)liTime; + LONGLONG Time; + + Time = liTime-s.HighPart; + Time = 32; + Time += liTime-s.LowPart; /* Extract millisecond from time and convert time into seconds */ TimeFields-Milliseconds = (CSHORT) ((Time % TICKSPERSEC) / TICKSPERMSEC); -147,6 +151,7 TimeFields-Month = (CSHORT) (CurMonth + 1); TimeFields-Day = (CSHORT) (Days + 1); } + /** * RtlTimeFieldsToTime[NTDLL.] *
Wineconsole feature request
Would it be possible for someone to add a feature to wineconsole so that when the child process exits the console isnt torn down immediatly? This would be very nice because some dos apps dont work when not run through the console and so it is impossible to see their command line syntax. nog.
What is a leap second
While I was looking through dlls/ntdll/time.c I came across the following two comments: FIXME: Compute the number of leap second corrections here and FIXME: get the GMT offset here What do these mean? nog.
What is a leap second
While I was looking through dlls/ntdll/time.c I came across the following two comments: FIXME: Compute the number of leap second corrections here and FIXME: get the GMT offset here What do these this mean? nog.
Re: What is a leap second
Advice: use it on Windows and check the result. Could someone compile this very simple test case under a system that has RtlTimeToTimeFields (windows 98 doesnt export this from ntdll or kernel32) and report the results? nog. timetest.c Description: Binary data
Re: What is a leap second
György, could you check which other includes can be used if winternl.h is absent? Else you''ll probably have to wait for somebody which has it to compile your test. This is included in the latest platform SDK but it should also be defined in ntddk.h. nog.
Re: improve scanf
Ooops, that patch has got an error in it, use this one instead.
ChangeLog:
* dlls/msvcrt/scanf.c
* dlls/msvcrt/scanf.h
Implement [ format specifier.
nog.
Index: dlls/msvcrt/scanf.c
===
RCS file: /home/wine/wine/dlls/msvcrt/scanf.c,v
retrieving revision 1.1
diff -u -r1.1 scanf.c
--- dlls/msvcrt/scanf.c 17 Aug 2002 01:22:00 - 1.1
+++ dlls/msvcrt/scanf.c 12 Oct 2002 17:04:57 -
-24,6 +24,7
*/
#include winbase.h
+#include winternl.h
#include msvcrt.h
#include msvcrt/conio.h
#include msvcrt/io.h
Index: dlls/msvcrt/scanf.h
===
RCS file: /home/wine/wine/dlls/msvcrt/scanf.h,v
retrieving revision 1.3
diff -u -r1.3 scanf.h
--- dlls/msvcrt/scanf.h 29 Sep 2002 18:00:23 - 1.3
+++ dlls/msvcrt/scanf.h 12 Oct 2002 17:05:01 -
-442,6 +442,79
}
}
break;
+ case _L_('['): {
+#ifdef WIDE_SCANF
+WCHAR *str = suppress ? NULL : va_arg(ap, WCHAR*);
+WCHAR *sptr = str;
+#else /* WIDE_SCANF */
+char *str = suppress ? NULL : va_arg(ap, char*);
+char *sptr = str;
+#endif /* WIDE_SCANF */
+ RTL_BITMAP bitMask;
+LPBYTE Mask;
+ int invert = 0; /* Set if we are NOT to find the chars */
+
+ /* Init our bitmap */
+#ifdef WIDE_SCANF
+ Mask = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
+ sizeof(WCHAR) * 32);
+ RtlInitializeBitMap(bitMask, Mask, sizeof(WCHAR) * 256);
+#else /* WIDE_SCANF */
+ Mask = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
+ sizeof(char) * 32);
+ RtlInitializeBitMap(bitMask, Mask, sizeof(char) * 256);
+#endif /* WIDE_SCANF */
+
+ /* Read the format */
+ format++;
+ if(*format == '^') {
+ invert = 1;
+ format++;
+ }
+ if(*format == ']') {
+ RtlSetBits(bitMask, ']', 1);
+ format++;
+ }
+while(*format (*format != ']')) {
+ if((*format == '-') (*(format + 1) != ']')) {
+ int n = 0;
+ for(;(n + *(format - 1)) *(format + 1); n++)
+ RtlSetBits(bitMask, n + *(format - 1), 1);
+ format++;
+ }
+ RtlSetBits(bitMask, *format, 1);
+ format++;
+ }
+/* read until char is not suitable */
+while ((width != 0) (nch != _EOF_)) {
+ if(!invert) {
+ if(RtlAreBitsSet(bitMask, nch, 1)) {
+#ifdef WIDE_SCANF
+ if (!suppress) *sptr++ = _CONVERT_(nch);
+#else /* WIDE_SCANF */
+ if (!suppress) *sptr++ = nch;
+#endif /* WIDE_SCANF */
+ } else
+ break;
+ } else {
+ if(RtlAreBitsClear(bitMask, nch, 1)) {
+#ifdef WIDE_SCANF
+ if (!suppress) *sptr++ = _CONVERT_(nch);
+#else /* WIDE_SCANF */
+ if (!suppress) *sptr++ = nch;
+#endif /* WIDE_SCANF */
+ } else
+ break;
+ }
+st++;
+nch = _GETC_(file);
+if (width0) width--;
+}
+/* terminate */
+if (!suppress) *sptr = 0;
+ HeapFree(GetProcessHeap(), 0, Mask);
+}
+break;
default: FIXME(unhandled: %%%c\n, *format);
/* From spec: if a percent sign is followed by a character
* that has no meaning as a format-control character, that
is it winetest or me?
While cominuing on my msvcrt test, I ran accross the following anomily(mabe?). If I have ok(0 == 0, NULL) in my test, then everything works fine, but if I get ok(1 == 0, NULL) then the whole thing crashes with an exection to a write error. Anyone have any ides? nog.
msvcrt tests
Im trying to write regression tests for the sscanf function but ran into some problems. First, there were some conflicts with the defines in the headers with my linux ones, but that was fixed simply by defining USE_MSVCRT_PREFIX. Whenever I try to run the test it spews out an error: undefind reference to func_sscanf. Ofcourse there is no export for func_sscanf because it was prefixed to avoid a naming conflict with the unix defines. How do I get this to work? If its not prefixed, then there is a conflict but if it is then it cant find the export.
Re: msvcrt tests
Im trying to write regression tests for the sscanf function but ran into some problems. First, there were some conflicts with the defines in the headers with my linux ones, but that was fixed simply by defining USE_MSVCRT_PREFIX. Whenever I try to run the test it spews out an error: undefind reference to func_sscanf. Ofcourse there is no export for func_sscanf because it was prefixed to avoid a naming conflict with the unix defines. How do I get this to work? If its not prefixed, then there is a conflict but if it is then it cant find the export. Sorry, this is my fault, In my test I had START_TEST(scanf) instead of START_TEST(sscanf). It works now. nog.
Re: Major tidy up of Scroll.c to add foundations for flatscroll bars
I have used this code to implement flat scroll bars in two ways however I run into problems and I am looking for advice. Hi, I was thinking about implementing flatscrollbars but never got round to implement the Flatscrollbars itself. I thought about doig it like this: Subclass the window with flatscrollbars, with the Subclassing functions that I have implemented recently. Implement GetScrollBarInfo and use it to get all of the scrollbar properties like thump position and size, arrow sizes etc. Store an internal list of the System metricies (just like native) and then draw the control. All of the functions that pertain to flat scroll bars will just call their user counterparts and the same goes for messages. nog.
Exception while trying to install winace 2.2
While trying to get the winace 2.2 installer to run on wine, I got the following exception without any messages on the console: First chance exception: page fault on read access to 0x23c94fed in 32-bit code (0x23c94fed). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS: EIP:23c94fed ESP:40682e52 EBP:0040 EFLAGS:00010646( R- 00 DI Z- -P1 ) EAX: EBX:40682e66 ECX:038b EDX:00420654 ESI:0001 EDI:0044efb5 Stack dump: 0x40682e52 (_end+0x32cc32): 004209e2 40682e98 00420658 0x40682e62 (_end+0x32cc42): 00463047 0042066b 40682f44 0x40682e72 (_end+0x32cc52): 00463000 40c0 0001 40682f38 0x40682e82 (_end+0x32cc62): 40682e96 400fd024 00463042 0600 0x40682e92 (_end+0x32cc72): 00463000 2f440246 c81a4068 66b12fc3 0x40682ea2 (_end+0x32cc82): c19d6f8a 25b92f81 51634d58 33c04011 0x40682eb2 (_end+0x32cc92): 0011: sel=008f base=401133c0 limit=0fff 32-bit rw- Backtrace: =0 0x23c94fed (_end+0x1bc38885) (ebp=0040) 1 0x0002 (ebp=00505a4d) *** Invalid address 0x00505a4d (wace22.exe.EntryPoint+0xa2a0b) 0x23c94fed (_end+0x1bc38885): *** Invalid address 0x23c94fed (_end+0x1bc38885) -- no code -- It seemd to me that the stack frame(s?) got corrupted so I debugged further. It seems that the app throws an exception and catches it later on. I set a breakpoint on EXC_CallHandler where the backtrace still looked fine. Just before wine calls the exception handler, it pushes edx and then edi onto the stack, then the handler gets called: call *%edx. This puts excecution into 0x420658 which calls 0x4206ac. The assembly code at 0x4206ac looks like this: 0x004206ac (wace22.exe.+0x1f6ac in C:\wace22.exe): xorl %eax,%eax 0x004206ae (wace22.exe.+0x1f6ae in C:\wace22.exe): popl %esi 0x004206af (wace22.exe.+0x1f6af in C:\wace22.exe): movl %fs:0x0(%eax),%ebx 0x004206b2 (wace22.exe.+0x1f6b2 in C:\wace22.exe): movl 0x0(%ebx),%ebx 0x004206b4 (wace22.exe.+0x1f6b4 in C:\wace22.exe): leal 0xffd6(%ebx),%esp 0x004206b7 (wace22.exe.+0x1f6b7 in C:\wace22.exe): popl %ebp This last pop is what makes the backtrace weird, before this the backtrace looks like: =0 0x004206b7 (wace22.exe.+0x1f6b7 in C:\wace22.exe) (ebp=40570938) 1 0x400c84c0 (EXC_RtlRaiseException+0x10c(rec=0x405709dc, context=0x40570a34) [exception.c:214] in libntdll.dll.so) (ebp=405709c0) 2 0x400d26e9 (do_segv+0x1a5(context=0x40570d1c, trap_code=0x400d2b98, cr2=0x40570a50, err_code=0x1) [signal_i386.c:798] in libntdll.dll.so) (ebp=40570a2c) 3 0x400d2b4c (segv_handler+0x3c(__signal=0x2b, __context=0x2b) [[signal_i386.c:986] in libntdll.dll.so) (ebp=40570d28) 4 0x008f (ebp=) But after it, it looks like this: =0 0x004206c1 (wace22.exe.+0x1f6c1 in C:\wace22.exe) (ebp=0040) 1 0x0002 (ebp=00505a4d) *** Invalid address 0x00505a4d (wace22.exe.EntryPoint+0xa2a0b) Is this normal? If I just continue from this point then the first exception will be thrown but quite a lot of functions get called between here and that exception. The exception handler never does return. Any one have any ideas as to what might go wrong here? nog.
