Menu
▾
▴
reactos-kernel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(438) |
Nov
(183) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(132) |
May
(466) |
Jun
(366) |
Jul
(392) |
Aug
(31) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
|
From: Phillip S. <ps...@cf...> - 2001-10-26 16:39:17
|
What is shlwapi? At 02:51 PM 10/26/2001 +0000, you wrote: >Hi All! >Is there anyone else other than me porting wine to ROS? I have made some >progress. I'm working on shlwapi and comctl32 for now. Wow what a mess! >With shlwapi, I've moved headers in to the local directory instead of placing >them in the include/wine. Worry about that later. Browsing through the >wine headers is a chore. > >Need help with windres, anyone have good examples of adding texted bin >code in the rc files? ~Icon stuff~. > >Remember this is not a futile effort, the objective is to have a gui up >and running for the gui/apps programmers. For me, this is a quick way to >learn Windows after purposely avoiding it for so long.. > > >Thanks, >James ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Casper H. <ch...@us...> - 2001-10-26 15:31:13
|
> -----Original Message----- > From: jim...@ad... > [mailto:jim...@ad...] > Sent: 26. oktober 2001 16:52 > To: ros...@re... > Subject: [ros-kernel] Re: Sharing code with wine > > > Hi All! > Is there anyone else other than me porting wine to ROS? I'm looking into it. > I'm working on shlwapi and comctl32 for now. Wow what a mess! You're right about that! > With shlwapi, I've moved headers in > to the local directory instead of placing them in the > include/wine. Worry about that later. Browsing through the > wine headers is a chore. I'm trying to use the wine DLL's with minimal changes to the code and headers. There are all sorts of problems with the headers under mingw. I've put the wine code (from CVS) into a directory parallel to ReactOS. Then I will create makefiles compatible with the ReactOS build system. If you're changing the wine headers, please make sure that you can easily update the ReactOS version from the wine version in the future. Possibly ask the wine people if a restructuring is OK with them. - Casper ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: James T. <jim...@ad...> - 2001-10-26 14:54:38
|
Hi All! Is there anyone else other than me porting wine to ROS? I have made some progress. I'm working on shlwapi and comctl32 for now. Wow what a mess! With shlwapi, I've moved headers in to the local directory instead of placing them in the include/wine. Worry about that later. Browsing through the wine headers is a chore. Need help with windres, anyone have good examples of adding texted bin code in the rc files? ~Icon stuff~. Remember this is not a futile effort, the objective is to have a gui up and running for the gui/apps programmers. For me, this is a quick way to learn Windows after purposely avoiding it for so long.. Thanks, James ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Steven E. <Ste...@kn...> - 2001-10-26 12:05:32
|
Sure, I'll test it. Steve -----Original Message----- From: Eric Kohl To: ros...@re... Sent: 10/26/01 6:43 AM Subject: [ros-kernel] Re: BUG report - boot failure under vmware "Steven Edwards" <Ste...@kn...> wrote: > > System boots on real hardware. screenshoot attached. > ########################################### > > This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. > For more information, connect to http://www.F-Secure.com/ > > This is a bug in the ide driver. Neither xHalIoReadPartitionTable() nor xHalpQueryDriveLayout() return STATUS_INVALID_PARAMETER (0xC000000D) directly. Can I send you an experimental atapi driver for testing? At present it tries to find ide controllers and drives without resetting them. Identifying drives is not implemented yet. Perhaps this driver will also find your second disk. Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
|
From: Eric K. <ek...@rz...> - 2001-10-26 10:44:10
|
"Steven Edwards" <Ste...@kn...> wrote: > > System boots on real hardware. screenshoot attached. > ########################################### > > This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. > For more information, connect to http://www.F-Secure.com/ > > This is a bug in the ide driver. Neither xHalIoReadPartitionTable() nor xHalpQueryDriveLayout() return STATUS_INVALID_PARAMETER (0xC000000D) directly. Can I send you an experimental atapi driver for testing? At present it tries to find ide controllers and drives without resetting them. Identifying drives is not implemented yet. Perhaps this driver will also find your second disk. Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert C. <rob...@it...> - 2001-10-26 04:29:45
|
----- Original Message ----- From: "Phillip Susi" <ps...@cf...> To: <ros...@re...> Sent: Friday, October 26, 2001 3:16 AM Subject: [ros-kernel] Re: Sharing code with wine + 16 bit support > Running the 16bit code is not a problem, you just create a 16bit v86 mode > code segment selector and jump to it. It's all of the support code for > 16bit apps that is difficult. DOS apps expect to be able to make interrupt > calls to dos as well as the bios, and be able to hook interrupts from > hardware. They also expect to be able to directly access hardware via IO > ports. Just to support DOS then, we have to write a fake bios, dos, and > have the VDM fake interrupts and fake IO port access. Then for windows 3.1 > support, you have to basically rewrite all of windows 3.1 to run inside the > VDM, so this is not trivial. Sure. To help though, freeDOS can provide the DOS code, and I'd have thought bochs now it's under GPL could provide the BIOS emulation - or at least a large chunk of it. Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Steven E. <Ste...@kn...> - 2001-10-25 22:01:14
|
I've had this problem for a while but just been to lazy to report it. Here is my setup - I have 2 harddrives C:\ 4.1gig fat32 D:\ 32.5gig fat32 It seems that ROS isnt seeing my secound drive at all. From what I can tell on startup it only gets the drive paramters for my boot drive. When I try to Change Drive at the reactos prompt this is the result. C:\reactos>D: (io/create.c:89) Parent is Directory which is not a device type C:\reactos> Is there only support for one Hard Disk? Thanks Steven########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
|
From: Steven E. <Ste...@kn...> - 2001-10-25 22:00:05
|
I just installed it, pulled down a new copy of the cvs tree and rebuilt.
Everything seems to work as it did before.
Steven
-----Original Message-----
From: Eric Kohl
To: ros...@re...
Sent: 10/25/01 7:22 AM
Subject: [ros-kernel] New binutils & gcc release
Hi!
Yesterday I uploaded a new release of binutils and gcc to SourceForge.
This
release is available as Win32 *and* Linux cross version.
The new release fixes a few bugs:
- Fixed the 'export by ordinal' bug in dlltool.
- Added missing c++ compiler files (c++.exe and g++.exe).
- Fixed a few fastcall bugs ('gcc -shared' is partially working).
- Optimized and stripped executables.
Please download this release and test it.
Best regards,
Eric Kohl
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
|
|
From: Aliberti E. <ea...@io...> - 2001-10-25 21:35:12
|
Bo Branten published the GPLed NTIFS.H version 30 (http://www.acc.umu.se/~bosse/): Corrected: KINTERRUPT OBJECT_TYPE Added: Defines: More FSCTL_XXX Data types: BITMAP_RANGE CreateMailslot in EXTENDED_IO_STACK_LOCATION CreatePipe in EXTENDED_IO_STACK_LOCATION QueryQuota in EXTENDED_IO_STACK_LOCATION MAILSLOT_CREATE_PARAMETERS MBCB NAMED_PIPE_CREATE_PARAMETERS PRIVATE_CACHE_MAP_FLAGS PRIVATE_CACHE_MAP SECURITY_CLIENT_CONTEXT SHARED_CACHE_MAP VACB Function prototypes: HalQueryRealTimeClock HalSetRealTimeClock PsGetProcessExitTime PsIsThreadTerminating PsLookupProcessThreadByCid PsLookupThreadByThreadId SeQueryAuthenticationIdToken Externals: KeServiceDescriptorTable SePublicDefaultDacl SeSystemDefaultDacl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Aliberti E. <ea...@io...> - 2001-10-25 21:23:13
|
Eric Kohl wrote: >> What is the format of nls files? They don't appear to be PE files. >> >There is a format description at: http://webcenter.ru/~kazarn/eng/nls.htm > Should we follow that format for ros NLS files, or design a new one (or design a compatible one as we did with registry hives)? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-10-25 20:59:08
|
"Phillip Susi" <ps...@cf...> wrote: > What is the format of nls files? They don't appear to be PE files. > There is a format description at: http://webcenter.ru/~kazarn/eng/nls.htm It describes the format of the codepage files (c_xxx.nls). Locale.nls seems to contain the locale information for all listed countries (detailed format unknown). Unicode.nls seems to contain the unicode upcase and lowercase tables (detailed format unknown). Any more details?? - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-10-25 20:53:13
|
"KJK::Hyperion" <no...@li...> wrote:
> At 08.53 25/10/2001 -0400, you wrote:
> >I thought the translation tables were in the *.nls files, which were
> >mapped into memory as needed?
>
> Some of them are mapped right during boot. Put the boot-time /SOS switch
to
> see it, they're the first thing the loader reads after the kernel, the
hal,
> the system hive and the VGA font
In my local source tree I changed the hardcoded translations in ntoskrnl.exe
(rtl/nls.c) to a table driven concept. As soon as the memory pools are
available the default translation tables are allocated and initialized.
Although this doesn't change much, we can load the .nls files later, update
the table pointers and free the old buffers. Of course this must happen
before smss is started.
Btw, the german win2k loads:
c_1252.nls (ansi codepage)
c_850.nls (oem codepage)
l_intl.nls (???)
- Eric Kohl
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: Phillip S. <ps...@cf...> - 2001-10-25 20:27:33
|
What is the format of nls files? They don't appear to be PE files. At 08:03 PM 10/25/2001 +0200, you wrote: >At 08.53 25/10/2001 -0400, you wrote: >>I thought the translation tables were in the *.nls files, which were >>mapped into memory as needed? > >Some of them are mapped right during boot. Put the boot-time /SOS switch >to see it, they're the first thing the loader reads after the kernel, the >hal, the system hive and the VGA font > >For those who don't beleive how nls tables are loaded, get objdir (NT DDK) >or WinObj (from Sysinternals) and have a look into the \NLS directory ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Aliberti E. <ea...@io...> - 2001-10-25 19:49:46
|
>For those who don't beleive how nls tables are loaded, get objdir (NT DDK) >or WinObj (from Sysinternals) and have a look into the \NLS directory Or ReactOS own objdir... ;-) ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: KJK::Hyperion <no...@li...> - 2001-10-25 19:40:01
|
At 08.53 25/10/2001 -0400, you wrote: >I thought the translation tables were in the *.nls files, which were >mapped into memory as needed? Some of them are mapped right during boot. Put the boot-time /SOS switch to see it, they're the first thing the loader reads after the kernel, the hal, the system hive and the VGA font For those who don't beleive how nls tables are loaded, get objdir (NT DDK) or WinObj (from Sysinternals) and have a look into the \NLS directory ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Aliberti E. <ea...@io...> - 2001-10-25 19:35:31
|
Phillip Susi wrote: > > I thought the translation tables were in the *.nls files, which were mapped > into memory as needed? Loaded by NTLDR at startup and demand loaded by NTOSKRNL.EXE? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jakob E. <ja...@vm...> - 2001-10-25 17:34:26
|
On Thu, Oct 25, 2001 at 01:16:58PM -0400, Phillip Susi wrote: > Running the 16bit code is not a problem, you just create a 16bit v86 mode > code segment selector and jump to it. It's all of the support code for > 16bit apps that is difficult. DOS apps expect to be able to make interrupt > calls to dos as well as the bios, and be able to hook interrupts from > hardware. They also expect to be able to directly access hardware via IO > ports. Just to support DOS then, we have to write a fake bios, dos, and > have the VDM fake interrupts and fake IO port access. Then for windows 3.1 > support, you have to basically rewrite all of windows 3.1 to run inside the > VDM, so this is not trivial. > > At 06:44 PM 10/25/2001 +0200, you wrote: > Right. Emulation of 16 bit code should be fairly trivial, anyway, since > it's mostly a feature of the Intel architecture > Could not this wait for later? There is 16-bit windows support in wine and there is FreeDOS. Sometime in the distant future this could surely be integrated into ReactOS? jakob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-10-25 17:21:48
|
Running the 16bit code is not a problem, you just create a 16bit v86 mode code segment selector and jump to it. It's all of the support code for 16bit apps that is difficult. DOS apps expect to be able to make interrupt calls to dos as well as the bios, and be able to hook interrupts from hardware. They also expect to be able to directly access hardware via IO ports. Just to support DOS then, we have to write a fake bios, dos, and have the VDM fake interrupts and fake IO port access. Then for windows 3.1 support, you have to basically rewrite all of windows 3.1 to run inside the VDM, so this is not trivial. At 06:44 PM 10/25/2001 +0200, you wrote: Right. Emulation of 16 bit code should be fairly trivial, anyway, since it's mostly a feature of the Intel architecture ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: KJK::Hyperion <no...@li...> - 2001-10-25 16:58:43
|
At 22.45 24/10/2001 +0200, you wrote: > > Does wine support 16bit apps? We don't, and I don't see any need to > > either. It has been many many years since we left the 16bit world > > behind. We finally even got rid of the ISA bus. I think we can drop > > 16bit > > windows/dos as well. >Anyway, 16-bit in NT is emulated AFAIK with the WOW (Windows On Windows). Right. Emulation of 16 bit code should be fairly trivial, anyway, since it's mostly a feature of the Intel architecture >That can be done separately, no? And what about win32 console apps? Since >they depends on the console, could they be affected by the absence of this >support? Only in Windows 95, where consoles are all DOS virtual machines. NT consoles are a service provided by the Win32 (AKA Client-server runtime) subsystem, csrss.exe (it does expose NTVDM/WOW specific extensions through kernel32.dll, though) ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-10-25 12:57:40
|
I thought the translation tables were in the *.nls files, which were mapped into memory as needed? At 03:08 AM 10/25/2001 +0000, you wrote: >Hi Eric, >Okay, I believe the unicode goes into kernel32.dll as "codepage"'s. I'm using >a Process Explorer and a Dll Explorer to verify this. Yeah! What should I >do? Write it into the kernel32.dll? >James ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-10-25 12:42:18
|
Hi!
Yesterday I uploaded a new release of binutils and gcc to SourceForge. This
release is available as Win32 *and* Linux cross version.
The new release fixes a few bugs:
- Fixed the 'export by ordinal' bug in dlltool.
- Added missing c++ compiler files (c++.exe and g++.exe).
- Fixed a few fastcall bugs ('gcc -shared' is partially working).
- Optimized and stripped executables.
Please download this release and test it.
Best regards,
Eric Kohl
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: Aliberti E. <ea...@io...> - 2001-10-25 06:51:44
|
>Hi Eric, >Okay, I believe the unicode goes into kernel32.dll as "codepage"'s. I'm using >a Process Explorer and a Dll Explorer to verify this. Yeah! What should I >do? Write it into the kernel32.dll? I think they should go "into" ntdll, to be accessible from any subsystem, not only from Win32. I am not sure, but that library is loaded in a special way into the address space of each process, therefore probably it is a loader task mapping kernel mode sections that contain the CPs into a process' space. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Steven E. <Ste...@kn...> - 2001-10-25 04:01:50
|
As a short term dirty hack, couldnt you do both? Load them as a user space dll and as a kernel mode driver? -----Original Message----- From: James Tabor To: ros...@re... Sent: 10/24/01 11:08 PM Subject: [ros-kernel] Re: Unicode Library Eric Kohl wrote: > > "Aliberti Emanuele" <ea...@io...> wrote: > > > > > >I finished porting unicode over to ROS. It's about 800 kbytes+ zipped. > So, > > > > What is the "unicode library"? > > > I guess he is talking about the ansi/oem<->unicode conversion tables from > Wine. > > I'm not sure if we should use it as a dll. The main problem is that the > conversion tables must be accessible from kernel *and* user mode. Loading > them as a kernel mode driver will not allow us to use non-default code-page > tables in user mode. Loading them as a dll does not allow us to use them in > kernel mode. > > IIRC, WinNT loads the default code-page tables (oem-unicode, ansi-unicode > and unicode case-table) into a named memory section (use winobj to see them) > and maps a view into every process. The code-page tables can also be loaded > separately by MultiByteToWideChar() and WideCharToMultiByte(), at least I > think they do so. > > Regards, > > Eric Kohl > Hi Eric, Okay, I believe the unicode goes into kernel32.dll as "codepage"'s. I'm using a Process Explorer and a Dll Explorer to verify this. Yeah! What should I do? Write it into the kernel32.dll? James ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
|
From: James T. <jim...@ad...> - 2001-10-25 03:11:29
|
Eric Kohl wrote: > > "Aliberti Emanuele" <ea...@io...> wrote: > > > > > >I finished porting unicode over to ROS. It's about 800 kbytes+ zipped. > So, > > > > What is the "unicode library"? > > > I guess he is talking about the ansi/oem<->unicode conversion tables from > Wine. > > I'm not sure if we should use it as a dll. The main problem is that the > conversion tables must be accessible from kernel *and* user mode. Loading > them as a kernel mode driver will not allow us to use non-default code-page > tables in user mode. Loading them as a dll does not allow us to use them in > kernel mode. > > IIRC, WinNT loads the default code-page tables (oem-unicode, ansi-unicode > and unicode case-table) into a named memory section (use winobj to see them) > and maps a view into every process. The code-page tables can also be loaded > separately by MultiByteToWideChar() and WideCharToMultiByte(), at least I > think they do so. > > Regards, > > Eric Kohl > Hi Eric, Okay, I believe the unicode goes into kernel32.dll as "codepage"'s. I'm using a Process Explorer and a Dll Explorer to verify this. Yeah! What should I do? Write it into the kernel32.dll? James ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: David W. <we...@cw...> - 2001-10-24 22:57:50
|
On Wed, Oct 24, 2001 at 11:21:15PM +0200, Aliberti Emanuele wrote: > ExAllocatePoolWithTag() > > what is a pool type value 0x10 ? > > It seems it is not documented at all. > According to the softice documentation there is more than one (in fact a large number) of paged pools, apparently to reduce contention, so perhaps it refers to a particular one of those. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
8 messages has been excluded from this view by a project administrator.
