DPMI - The joys and sorrows therein...
Jed
I'm trying to write a low level disk sector reading header for some
work I'm doing for a project, and I've been having a bit of difficulty.
After finding out that Thunking is not necessary (nor wanted) for my
project, I decided to move the whole kit and kaboodle to DOS. 32-bit
DOS gives me the flexibility I'd like in almost every area. But there's
a problem: having a little trouble with the DPMI for simulated real
mode interrupt calls on int13h. I've not even tried the actual disk
reading routine, but here's the code I have for an LBA check.
The actual call is
AX=4200
BX=55AA
DX=0080
Int13h
Should return the swapped value 0xAA55 in BX, but it doesn't appear to
have changed the structure at all.
Compiler: OpenWatcom 1.4 package
Host OS: Windows
Target OS: Dos 6.22+Dos32A
#include <iostream>
struct intSim;
unsigned short allocDOS(unsigned short);
unsigned short mapMem(unsigned short);
unsigned short simulateInt(unsigned short, intSim* data);
//This structure is used for interrupt simulations in DOS32A
struct intSim
{
unsigned long regEDI, regESI, regEBP, res1, regEBX, regEDX, regECX,
regEAX;
unsigned short CPUflags, regES, regDS, regFS, regGS, regIP, regCS,
regSP, regSS;
};
//Allocates our DOS using DOS32A's DPMI 0100h - this is called via
int31
//bx is the number of blocks
//if the carry is set, ax is set to 0 and we can test on the other end
#pragma aux allocDOS = \
"mov ax, 0100h" \
"int 31h"\
"jnc @@f0"\
"xor ax, ax"\
"@@f0: nop"\
parm [bx] \
value [ax] \
modify[ax bx];
//Maps the memory from real mode to our protected mode - uses DPMI
0002h
//bx is the real mode's segment
//ax returns the mapped address
#pragma aux mapMem = \
"mov ax, 0002h" \
"int 31h"\
"jnc @@f1"\
"xor ax, ax"\
"@@f1: nop"\
parm [bx] \
value [ax] \
modify [ax bx];
//This function calls our simulated interrupt using DPMI 0300h
//Checks for failure, and sets AX to AA55 if there is no failure.
//Does not allow for passing in of CX parameter - this is assumed to be
0!
//Needs the loadds to get the data segment for our structure
//This pulls in DI as a dummy, since DS is loaded (= ES), but we need
the offset
#pragma aux simulateInt loadds = \
"mov ax, 0300h" \
"xor cx, cx" \
"int 31h" \
"jc @@f2" \
"mov ax, 0AA55h" \
"@@f2: nop" \
parm [bx] [di esi] \
value [ax] \
modify [ax bx di edi];
void main()
{
//Basic modus operandi
// 1) allocate some DOS memory using DPMI 0100h
// 2) store address of our allocated memory
// 3) map address to linear address
// 4) call simulated real mode interrupt using DPMI 0300h
// -this points to our buffer DS:SI from 1)
// 5) read from our mapped memory
// YIKES!
unsigned short aMem, mpdMem, error;
intSim blue;
aMem=allocDOS(38);
std::cout<<"Real mode address before mapping is: "<<aMem<<"\n";
mpdMem=mapMem(aMem);
std::cout<<"Mapped address is: "<<mpdMem<<"\n";
//Simple LBA Installation test
blue.regEAX=0x4100;
blue.regEBX=0x55AA;
blue.regEDX=0x0080;
blue.res1=0x0;
error=simulateInt(0x13, &blue);
std::cout<<"EAX (AA55h means no failure) = "<<error<<"\n";
//Now blue should contain BX swapped around...
std::cout<<"EBX="<<blue.regEBX<<"\n";
}
Please note that the following code worked for this call, but is
impractical for passing buffer pointers in DS:SI :
unsigned short int13hBX(unsigned short, unsigned short, unsigned short,
unsigned short, unsigned short*);
unsigned short PDisk::hasLBA()
{
unsigned short blue; //change to support given drive
blue=int13hBX(0x4100, 0x55AA, 0x0, 0x0080, 0x0);
return blue;
}
#pragma aux int13hBX loadds= \
"int 13H" \
parm [ax] [bx] [cx] [dx] [di esi] \
value [bx]\
modify[ax bx cx dx di esi];
If the rest of the code is also faulty in concept .... my only excuse
is that I haven't tried this flat 32 mode at all before. I'd appreciate
your input on making int13h workable in a header...
Thanks in advance,
Jed
Rod Pemberton
"Jed" <jedidiah...@gmail.com> wrote in message
news:1137739470....@g47g2000cwa.googlegroups.com...
> Greetings!
>
> I'm trying to write a low level disk sector reading header for some
> work I'm doing for a project, and I've been having a bit of difficulty.
Fine.
> #include <iostream>
<massive code snip>
Ouch, that looks painful to me.
> If the rest of the code is also faulty in concept .... my only excuse
> is that I haven't tried this flat 32 mode at all before. I'd appreciate
> your input on making int13h workable in a header...
It appears you are using C++, I don't know how to program in C++. But I've
appended, after my signature, a rework of Chris Giese's DJGPPLBA.C. This
has Int 0x13 LBA routines. You should be able to figure out the other DOS,
BIOS calls using DPMI from this. But, I also have non-LBA C disk routines
hanging around here somewhere if you need them. Also, DJGPPLBA has three
versions of the main routines: DJGPP, OpenWATCOM Real-Mode DOS, and
OpenWATCOM "Protected-Mode" DOS (i.e., DPMI/dos-extender). It compiles
clean for OW1.3. It should hopefully do so for OW1.4.
Rod Pemberton
/***************************************************************************
**
LBA version of biosdisk() for DJGPP and WATCOM
WATCOM porting and DJGPP restructuring by Rod Pemberton
Changes: Feb 19, 2005
The changes are also public domain (no copyright).
LBA version of biosdisk() for DJGPP
Chris Giese <gee...@execpc.com> http://my.execpc.com/~geezer
Release date: Jan 2, 2004
This code is public domain (no copyright).
You can do whatever you want with it.
DJGPP: gcc -O2 -o djgpplba.exe djgpplba.c
WATCOM: wcl386/l=dos4g djgpplba.c
wcl/l=dos djgpplba.c
****************************************************************************
*/
#include <stdio.h> /* printf() */
#include <string.h> /* memset() */
#include <bios.h> /* _DISK_... */
#ifdef __DJGPP__
#include <dpmi.h> /* __dpmi_regs, __dpmi_int() */
#include <go32.h> /* _go32_info_block, __tb, dosmemget(), dosmemput() */
__dpmi_regs r;
#define HANDLE_PRAGMA_PACK_PUSH_POP 1
#endif
/* end __DJGPP__ */
#ifdef __WATCOMC__
#include <i86.h> /* regs, sregs, int86x() int386x() */
#include <stdlib.h> /* atexit */
union REGS r;
struct SREGS s;
struct {
long EDI,ESI,EBP,rsvd,EBX,EDX,ECX,EAX;
short flags,ES,DS,FS,GS,IP,CS,SP,SS;
} RMI;
/* tb used to setup transfer buffer below 1st megabyte (DJGPP __tb) */
/* DOS can only access the first 1Mb of memory */
/* tb used to save return information from DOS calls */
void *tb;
unsigned short sel; /* sel needed to free allocated memory, don't use */
#endif
/* end __WATCOMC__ */
#define BPS 512 /* bytes per sector for disk */
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint32_t;
typedef unsigned long long uint64_t;
#pragma pack(push,1)
typedef struct
{
uint8_t packet_len;
uint8_t reserved1;
uint8_t nsects;
uint8_t reserved2;
uint16_t buf_offset;
uint16_t buf_segment;
uint64_t lba;
} lba_command_packet;
#pragma pack(pop)
/***************************************************************************
**
****************************************************************************
*/
#ifdef __WATCOMC__
#define WAT_TB 0x4000
/* setup tb - transfer buffer for dos calls in memory below 1Mb */
void free_dos_mem(void)
{
#ifdef __386__
r.w.ax=0x0101; /* free dos memory */
r.w.dx=sel;
int386(0x31,&r,&r);
#else
free (tb);
#endif
}
void get_dos_mem(void)
{
#ifdef __386__
r.w.ax=0x0100; /* allocate dos memory, no __tb in WATCOM */
r.w.bx=WAT_TB>>4; /* 0400h is 04000h (16384 bytes) in paragraphs (16
bytes) */
int386(0x31,&r,&r);
sel = r.w.dx;
tb = (void *)(r.w.ax<<4);
#else
tb = malloc (16384);
if (tb==NULL)
{
printf("RM malloc failed.");
exit(1);
}
#endif
}
#endif
/***************************************************************************
**
****************************************************************************
*/
int lba_biosdisk(unsigned int13_drive_num, int cmd, unsigned long lba,
unsigned nsects, void *buf)
{
/* RP - this function is large and there were so many #ifdef's that I */
/* decided to just separate this function into three sections: */
/* DJGPP, WATCOM PM, WATCOM RM */
/* It really needs to be broken down into smaller functions... */
#ifdef __DJGPP__
/* DJGPP section */
lba_command_packet lba_cmd_pkt;
/* INT 13h AH=42h/AH=43h command packet: */
unsigned tries, err = 0;
if(cmd != _DISK_READ && cmd != _DISK_WRITE)
return 0x100;
/* make sure the DJGPP or WATCOM transfer buffer
(in conventional memory) is big enough */
if(BPS * nsects + sizeof(lba_command_packet) >
_go32_info_block.size_of_transfer_buffer)
return 0x100;
/* make sure drive and BIOS support LBA. Note that Win95 DOS box
emulates INT 13h AH=4x if they are not present in the BIOS. */
r.x.bx = 0x55AA;
r.h.dl = int13_drive_num;
r.h.ah = 0x41;
__dpmi_int(0x13, &r);
if(r.x.flags & 0x0001) /* carry bit (CY) is set */
return 0x100;
/* fill in the INT 13h AH=4xh command packet */
memset(&lba_cmd_pkt, 0, sizeof(lba_command_packet));
lba_cmd_pkt.packet_len = sizeof(lba_command_packet);
lba_cmd_pkt.nsects = nsects;
/* use start of transfer buffer
for data transferred by BIOS disk I/O... */
lba_cmd_pkt.buf_offset = 0;
lba_cmd_pkt.buf_segment = __tb >> 4;
lba_cmd_pkt.lba = lba;
/* ...use end of transfer buffer for the command packet itself */
dosmemput(&lba_cmd_pkt, sizeof(lba_command_packet), __tb + BPS *
nsects);
/* fill in registers for INT 13h AH=4xh */
r.x.ds = (__tb + BPS * nsects) >> 4;
r.x.si = (__tb + BPS * nsects) & 0x0F;
r.h.dl = int13_drive_num;
/* if writing, copy the data to conventional memory now */
if(cmd == _DISK_WRITE)
dosmemput(buf, BPS * nsects, __tb);
/* make 3 attempts */
for(tries = 3; tries != 0; tries--)
{
r.h.ah = (cmd == _DISK_READ) ? 0x42 : 0x43;
__dpmi_int(0x13, &r);
err = r.h.ah;
if((r.x.flags & 0x0001) == 0)
{
/* if reading, copy the data from conventional memory now */
if(cmd == _DISK_READ)
dosmemget(__tb, BPS * nsects, buf);
return 0;
}
/* reset disk */
r.h.ah = 0;
__dpmi_int(0x13, &r);
}
return err;
#endif
/* end DJGPP section */
#ifdef __WATCOMC__
#ifdef __386__
/* WATCOM PM section */
lba_command_packet lba_cmd_pkt;
/* INT 13h AH=42h/AH=43h command packet: */
unsigned tries, err = 0;
if(cmd != _DISK_READ && cmd != _DISK_WRITE)
return 0x100;
/* make sure the DJGPP or WATCOM transfer buffer
(in conventional memory) is big enough */
if(BPS * nsects + sizeof(lba_command_packet) >
WAT_TB) /* 04000h (16384) bytes for WATCOM above */
return 0x100;
/* make sure drive and BIOS support LBA. Note that Win95 DOS box
emulates INT 13h AH=4x if they are not present in the BIOS. */
RMI.EBX = 0x55AA;
RMI.EDX = int13_drive_num;
RMI.EAX = (0x41<<8);
r.w.ax=0x0300; /* simulate real mode interrupt */
r.h.bl=0x13; /* int 0x13 */
r.h.bh=0;
r.w.cx=0;
s.es=FP_SEG(&RMI);
r.x.edi=FP_OFF(&RMI);
int386x(0x31, &r, &r, &s);
if (RMI.flags & 0x0001) /* carry bit (CY) is set */
return 0x100;
/* fill in the INT 13h AH=4xh command packet */
memset(&lba_cmd_pkt, 0, sizeof(lba_command_packet));
lba_cmd_pkt.packet_len = sizeof(lba_command_packet);
lba_cmd_pkt.nsects = nsects;
/* use start of transfer buffer
for data transferred by BIOS disk I/O... */
lba_cmd_pkt.buf_offset = (unsigned long)tb & 0x0F;
lba_cmd_pkt.buf_segment = (unsigned long)tb >> 4;
lba_cmd_pkt.lba = lba;
/* ...use end of transfer buffer for the command packet itself */
memcpy((char *)tb + BPS * nsects, &lba_cmd_pkt,
sizeof(lba_command_packet));
/* fill in registers for INT 13h AH=4xh */
RMI.DS = ((unsigned long)tb + BPS * nsects) >> 4;
RMI.ESI = ((unsigned long)tb + BPS * nsects) & 0x0F;
RMI.EDX = int13_drive_num;
/* if writing, copy the data to conventional memory now */
if(cmd == _DISK_WRITE)
memcpy(tb, buf, BPS * nsects);
/* make 3 attempts */
for(tries = 3; tries != 0; tries--)
{
RMI.EAX = (((cmd == _DISK_READ) ? 0x42 : 0x43)<<8);
r.w.ax=0x0300; /* simulate real mode interrupt */
r.h.bl=0x13; /* int 0x13 */
r.h.bh=0;
r.w.cx=0;
s.es=FP_SEG(&RMI);
r.x.edi=FP_OFF(&RMI);
int386x(0x31, &r, &r, &s);
err = (RMI.EAX >> 8) & 0x0F;
if((RMI.flags & 0x0001) == 0)
{
/* if reading, copy the data from conventional memory now */
if(cmd == _DISK_READ)
memcpy(buf, tb, BPS * nsects);
return 0;
}
/* reset disk */
RMI.EAX = 0;
r.w.ax=0x0300; /* simulate real mode interrupt */
r.h.bl=0x13; /* int 0x13 */
r.h.bh=0;
r.w.cx=0;
s.es=FP_SEG(&RMI);
r.x.edi=FP_OFF(&RMI);
int386x(0x31, &r, &r, &s);
}
return err;
/* end WATCOM PM section */
#else
/* WATCOM RM section */
lba_command_packet lba_cmd_pkt;
/* INT 13h AH=42h/AH=43h command packet: */
unsigned tries, err = 0;
if(cmd != _DISK_READ && cmd != _DISK_WRITE)
return 0x100;
/* make sure the DJGPP or WATCOM transfer buffer
(in conventional memory) is big enough */
if(BPS * nsects + sizeof(lba_command_packet) >
WAT_TB) /* 04000h (16384) bytes for WATCOM above */
return 0x100;
/* make sure drive and BIOS support LBA. Note that Win95 DOS box
emulates INT 13h AH=4x if they are not present in the BIOS. */
r.w.bx = 0x55AA;
r.h.dl = int13_drive_num;
r.h.ah = 0x41;
int86(0x13, &r, &r);
if (r.w.cflag & 0x0001) /* carry bit (CY) is set */
return 0x100;
/* fill in the INT 13h AH=4xh command packet */
memset(&lba_cmd_pkt, 0, sizeof(lba_command_packet));
lba_cmd_pkt.packet_len = sizeof(lba_command_packet);
lba_cmd_pkt.nsects = nsects;
/* use start of transfer buffer
for data transferred by BIOS disk I/O... */
lba_cmd_pkt.buf_offset = FP_OFF(tb);
lba_cmd_pkt.buf_segment = FP_SEG(tb);
lba_cmd_pkt.lba = lba;
/* ...use end of transfer buffer for the command packet itself */
movedata(FP_SEG(&lba_cmd_pkt), FP_OFF(&lba_cmd_pkt), FP_SEG((char
*)tb + BPS * nsects), FP_OFF((char *)tb + BPS * nsects),
sizeof(lba_command_packet));
/* fill in registers for INT 13h AH=4xh */
s.ds = FP_SEG((char *)tb + BPS * nsects);
r.w.si = FP_OFF((char *)tb + BPS * nsects);
r.h.dl = int13_drive_num;
/* if writing, copy the data to conventional memory now */
if(cmd == _DISK_WRITE)
movedata(FP_SEG(buf), FP_OFF(buf), FP_SEG(tb), FP_OFF(tb),
BPS * nsects);
/* make 3 attempts */
for(tries = 3; tries != 0; tries--)
{
r.h.ah = (cmd == _DISK_READ) ? 0x42 : 0x43;
int86x(0x13, &r, &r, &s);
err = r.h.ah;
if((r.w.cflag & 0x0001) == 0)
{
/* if reading, copy the data from conventional memory now */
if(cmd == _DISK_READ)
movedata(FP_SEG(tb), FP_OFF(tb),
FP_SEG(buf), FP_OFF(buf), BPS * nsects);
return 0;
}
/* reset disk */
r.h.ah = 0;
int86(0x13, &r, &r);
}
return err;
/* end WATCOM RM section */
#endif
#endif
}
/***************************************************************************
**
demo routines
****************************************************************************
*/
#define BPERL 16 /* byte/line for dump */
void dump(void *data_p, unsigned count)
{
unsigned char *data = (unsigned char *)data_p;
unsigned byte1, byte2;
while(count != 0)
{
for(byte1 = 0; byte1 < BPERL; byte1++)
{
if(count == 0)
break;
printf("%02X ", data[byte1]);
count--;
}
printf("\t");
for(byte2 = 0; byte2 < byte1; byte2++)
{
if(data[byte2] < ' ')
printf(".");
else
printf("%c", data[byte2]);
}
printf("\n");
data += BPERL;
}
}
/***************************************************************************
**
****************************************************************************
*/
int main(void)
{
char boot[BPS], mbr[BPS], *pte; /* partition table entry */
unsigned i, drive = 0x80;
unsigned long j;
#ifdef __WATCOMC__
atexit(free_dos_mem);
get_dos_mem();
#endif
/* read sector 0 of drive (the partition table; or MBR)
int13_drive_num = 0x80 for drive C: */
if(lba_biosdisk(drive, _DISK_READ, 0, 1, mbr))
{
printf("Error reading partition table on drive 0x%02X\n",
drive);
return 1;
}
printf("Dump of partition table on drive 0x%02X:\n", drive);
dump(mbr + 446, 64);
for(i = 0; i < 4; i++)
{
pte = mbr + 446 + 16 * i;
/* skip partition if size == 0 */
j = *(uint32_t *)(pte + 12);
if(j == 0)
continue;
/* read sector 0 of partition (the boot sector) */
j = *(uint32_t *)(pte + 8);
if(lba_biosdisk(drive, _DISK_READ, j, 1, boot))
{
printf("Error reading bootsector of drive 0x%02X, "
"partition %u\n", drive, i);
continue;
}
printf("Dump of bootsector for drive 0x%02X, "
"partition %u:\n", drive, i);
dump(boot, 64);
}
return 0;
}
John F
"Rod Pemberton" wrote:
>
> "Jed" wrote:
>> Greetings!
>>
>> I'm trying to write a low level disk sector reading header for some
>> work I'm doing for a project, and I've been having a bit of difficulty.
>
> Fine.
>
>> #include <iostream>
>
> <massive code snip>
>
> Ouch, that looks painful to me.
>
>> If the rest of the code is also faulty in concept .... my only excuse
>> is that I haven't tried this flat 32 mode at all before. I'd appreciate
>> your input on making int13h workable in a header...
>
> It appears you are using C++, I don't know how to program in C++. But
> I've
> appended, after my signature, a rework of Chris Giese's DJGPPLBA.C. This
> has Int 0x13 LBA routines. You should be able to figure out the other
> DOS,
> BIOS calls using DPMI from this. But, I also have non-LBA C disk routines
> hanging around here somewhere if you need them. Also, DJGPPLBA has three
> versions of the main routines: DJGPP, OpenWATCOM Real-Mode DOS, and
> OpenWATCOM "Protected-Mode" DOS (i.e., DPMI/dos-extender). It compiles
> clean for OW1.3. It should hopefully do so for OW1.4.
Sounds like something for the "how to" or "tutoials" section on the new-born
web site...
I copy-pasted the code to
http://www.openwatcom.org/index.php/Accessing_the_Harddisk_using_LBA_under_DPMI.
It would be nice to run a code-tidy to the sections... I could do this
within this week.
Rod, if you find some time to add some comments, tweaks etc., this would be
very nice!!
Adding the non LBA stuff seems a good idea too!
thanks for the useful snippet anyway!
(I knew there was something like that around somewhere but wasn't sure where
it is extremely useful for me too ... ;-) thanks)
John
<code snip>
Lynn McGuire
> work I'm doing for a project, and I've been having a bit of difficulty.
I dont have a clue what you are trying to do but you may want to
examine the following resources:
EditDisk - http://www.codeguru.com/Cpp/W-P/system/misc/article.php/c5709
Forensic: http://www.codeguru.com/cpp/w-p/system/misc/article.php/c5665/
ReadSector: http://www.codeguru.com/cpp/w-p/system/misc/article.php/c5765/
Reading physical memory in Win32:
Physmem: http://www.sysinternals.com/Information/TipsAndTrivia.html#PhysMem
In addition, my own DiskId32 is a Win32 app for getting hard drive
info: http://www.winsim.com/diskid32/diskid32.html
BTW, all DOS16/DOS32/Win16 apps are not supported in Win64 if you
have any concerns about obsolescence.
Lynn
Rod Pemberton
"John F" <frea...@freakyjoe.port5.com> wrote in message
news:dr33hn$v68$1...@www-1.scitechsoft.com...
>
> "Rod Pemberton" wrote:
> Sounds like something for the "how to" or "tutoials" section on the
new-born
> web site...
I think the most important part is that it shows DJGPP programmers how to do
it in OW.
> I copy-pasted the code to
>
http://www.openwatcom.org/index.php/Accessing_the_Harddisk_using_LBA_under_DPMI.
> It would be nice to run a code-tidy to the sections... I could do this
> within this week.
>
> Rod, if you find some time to add some comments, tweaks etc., this would
be
> very nice!!
I created an account, and I _appreciate_ not needing a valid email address
since I haven't used email in three years. I was locked/hacked/boofed out
of my main email account (non-ISP), and haven't bothered to setup my ISP's
email account... It was all *SPAM* anyway.
But, I'm completely _unfamiliar_ with Wiki editing. Other than the
"===Code/Demo===" title sections, I don't know how or why it is "boxing"
certain large pieces of the program together but then generating smaller
"boxes" for others... I couldn't see any method to join/unjoin the "boxes"
or some global setting for the page. Is this newline dependent or a width
setting?
Since I've found a few of Chris' PD code to be very useful. I think the
author/title/compile section should probably also be in a "box" even though
it is Public Domain code. But, I didn't see a way to "[edit]" that section.
>comments
for example ? to the web-page or the code?
I think the code is probably commented enough at least for a fairly new
DJGPP progarmmer with no familiarity with OW. It might be a little bit
harder to grasp for a new OW user. That's because, the 'transfer buffer'
method was based off of DJGGP code and OW1.3 doesn't have wrappers around
the DPMI calls. A new user might need a link to Ralph Brown's interrupt
list or a link to the html version of RBI on Delorie's DJGPP pages.
>tweaks
for example ? to the web-page or the code?
I think it would be nice if the users could click a link at the bottom and
get the complete code.
Maybe you could add a comments section to the page where anyone (no account
needed) could post comments/criticisms for a _limited_ time to see what
people want/need/_complain_ about in the Wiki... That is if you've got the
stomach for dealing with 'graffiti' and 'off-topic' comments...
Also, I didn't see a tutorials link. How do I get to that page or that PCI
tutorial from the "Main" page? Right now I can only find them on the
'Recent Changes' page...
Also, as I mentioned before, that code hasn't been tested with OW1.4 (I'm
out of hard disk space).
Rod Pemberton
Michal Necasek
>
> But, I'm completely _unfamiliar_ with Wiki editing.
>
http://meta.wikimedia.org/wiki/Help:Editing
(linked to from the OW wiki if you start editing a page). It should
have all the information you need to get started.
Michal
John F
Indeed it is... You should put the link on the frontpage too (maybe even at
the bottom of the bottom?)
(I came across it when parsing the page... but I didn't recall where...)
John
John F
"Michal Necasek" wrote:
> John F wrote:
>
>> Ask Michal to upload it as a compressed file... (no permissions on my
>> side here)
>>
> Yes, I can upload files; although right now I am uncertain whether the
> files should be part of the wiki or simply be placed on the FTP somewhere.
MHO: FTP is more flexible, Wiki is more userfriendly... but external links
can definitely do the Job...
How is backup? Is it it drawn synchronous? If not, a lot of dead links are
possible in case of a restore... (Had such a case myself some years ago on
an intranet farm...)
>>>Maybe you could add a comments section to the page where anyone (no
>>>account
>>>needed) could post comments/criticisms for a _limited_ time to see what
>>>people want/need/_complain_ about in the Wiki... That is if you've got
>>>the
>>>stomach for dealing with 'graffiti' and 'off-topic' comments...
>>
>>
>> ---> Michal? Is this possible? (I'm afraid it won't be possible...)
> >
> Isn't this what the "discussion" page is for?
The discussion page is rather on topic (the topic of the page where the
discussion-feature is used, which can be a user too!...) and should be used
to make changes transparent before commitment and to ask for comments.
What Rod seems to suggest here is some sort of general suggestion page.
- Which seams quite against the concept of a wiki, on second thought. -
Someone with a (constructive) comment should post it on the discussions page
of the target... if it is nice, and a large part of the community (at the
moment 2 or 3 more) find it useful and there is no contrary opinion, it
should be considered or discussed further.
So you might hit the point here with the discussion-page... There still is
the reference to this NGs for general Questions.
BTW: thanks for the <PRE></PRE> ;-) Much cleaner and I will use it in the
future...
(weird use of PRE: http://de.selfhtml.org/html/text/anzeige/pre_style.htm
really punches the eyes... have a look at the source... quite interesting)
(Heading says: Software-Development in german)
--
John
Rod Pemberton
"Michal Necasek" <mic...@scitechsoft.com> wrote in message
news:dr3s58$cm4$1...@www-1.scitechsoft.com...
> John F wrote:
>
> > What Rod seems to suggest here is some sort of general suggestion page.
> >
>
> Or, to put it differently, I don't think Wiki is so good for
> *discussing* matters, certainly not nearly as good as a newsgroup.
>
Sorry, I didn't even see a 'discussion' button...
I take it that's were one normally adds unimportant comments?
I told you wasn't too familiar with Wiki's!!!
Rod
John F
"Rod Pemberton" wrote:
> "John F" wrote:
>> "Rod Pemberton" wrote:
>
>> Sounds like something for the "how to" or "tutoials" section on the
> new-born
>> web site...
>
> I think the most important part is that it shows DJGPP programmers how to
> do
> it in OW.
Indeed. That's why I added it.
>> I copy-pasted the code to
>>
> http://www.openwatcom.org/index.php/Accessing_the_Harddisk_using_LBA_under_DPMI.
>> It would be nice to run a code-tidy to the sections... I could do this
>> within this week.
I already ran a tidy on the code... I haven't had a closer look at the
details, but it hardly ever breaks things, I never noticed it breaking
anything at all, you might have a look though...
>> Rod, if you find some time to add some comments, tweaks etc., this would
> be
>> very nice!!
>
> I created an account, and I _appreciate_ not needing a valid email address
> since I haven't used email in three years. I was locked/hacked/boofed out
> of my main email account (non-ISP), and haven't bothered to setup my ISP's
> email account... It was all *SPAM* anyway.
I know these troubles and took a free account at GMX (www.gmx.net) which has
a nice spamfilter ... 1G Mailspace does its best...
> But, I'm completely _unfamiliar_ with Wiki editing. Other than the
> "===Code/Demo===" title sections, I don't know how or why it is "boxing"
> certain large pieces of the program together but then generating smaller
> "boxes" for others... I couldn't see any method to join/unjoin the
> "boxes"
> or some global setting for the page. Is this newline dependent or a width
> setting?
Partially. It took me a while to remember the wiki things again.
It is a rather simple system:
One or more spaces at the beginning of a paragraph "enbox" this paragraph
and inherently switch it to monospace...
A single newline does not affect the layout, its just for readability in the
source, two in series, however, open a new paragraph.
> Since I've found a few of Chris' PD code to be very useful. I think the
> author/title/compile section should probably also be in a "box" even
> though
> it is Public Domain code. But, I didn't see a way to "[edit]" that
> section.
(Did you notice the edit-tab on top of the page?)
OK, I'll have a look at that...
(done, Rearranged it to get the Code up and the legal Info down... someone
intersted in the code should not have to read through miles of text to get
there ;-) but this can be changed whenever it is requested...
Could you explain the general functionality for someone who might find it
useful (that is: expand the very first sentence a little bit?)
>>comments
> for example ? to the web-page or the code?
The tricks that were used in the code, if they are useful out of the box in
other fields.
> I think the code is probably commented enough at least for a fairly new
> DJGPP progarmmer with no familiarity with OW.
That is indeed true! Good style. Easy to follow.
> It might be a little bit
> harder to grasp for a new OW user. That's because, the 'transfer buffer'
> method was based off of DJGGP code and OW1.3 doesn't have wrappers around
> the DPMI calls.
Could you add a short explaination on that, just in case someone is
wondering "why"? Would be nice (and good practice @Wiki ...)!
> A new user might need a link to Ralph Brown's interrupt
> list or a link to the html version of RBI on Delorie's DJGPP pages.
Um, nice suggestion! I'll add it.
(done @ bottom)
>>tweaks
> for example ? to the web-page or the code?
Code, critical sections, ... something like that.
Maybe we should somewhen (I don't have much time) create templates for
tutorials (see Wikipedias country templates) to ease creation of such a
tutorial... and to get consistent Information out of them. (same look and
feel etc...)
If I happen to have some more time off (2 weeks range) I'll have a short
look at templates in WIKI...
> I think it would be nice if the users could click a link at the bottom and
> get the complete code.
Ask Michal to upload it as a compressed file... (no permissions on my side
here)
> Maybe you could add a comments section to the page where anyone (no
> account
> needed) could post comments/criticisms for a _limited_ time to see what
> people want/need/_complain_ about in the Wiki... That is if you've got
> the
> stomach for dealing with 'graffiti' and 'off-topic' comments...
---> Michal? Is this possible? (I'm afraid it won't be possible...)
Wiki can revert any changes to a previous state so recovering is rather
simple. (If there is frequent abuse it will be necessary to block anonymous
posters...)
BTW.: on top of every page there is a discussion-tab, a history tab ...
> Also, I didn't see a tutorials link. How do I get to that page or that
> PCI
> tutorial from the "Main" page? Right now I can only find them on the
> 'Recent Changes' page...
http://www.openwatcom.org/index.php/Tutorials (a link there is available at
the front page)
I added a link under System Programming... :-) (I hope that's OK...)
[[Internal Link Here]] links to the Article called "Internal Link here" ...
JFI
> Also, as I mentioned before, that code hasn't been tested with OW1.4 (I'm
> out of hard disk space).
Oh... I'll add a comment (or a section... )
(not about your harddisk... or would you like a "donateAbit" button? ;-)
Could you add a list of compilers the code is tested on?
Thanks very much!
John
Michal Necasek
> Ask Michal to upload it as a compressed file... (no permissions on my side
> here)
>
Yes, I can upload files; although right now I am uncertain whether the
files should be part of the wiki or simply be placed on the FTP somewhere.
>>Maybe you could add a comments section to the page where anyone (no
>>account
>>needed) could post comments/criticisms for a _limited_ time to see what
>>people want/need/_complain_ about in the Wiki... That is if you've got
>>the
>>stomach for dealing with 'graffiti' and 'off-topic' comments...
>
>
> ---> Michal? Is this possible? (I'm afraid it won't be possible...)
>
Isn't this what the "discussion" page is for?
Michal
Michal Necasek
> MHO: FTP is more flexible, Wiki is more userfriendly...
>
That's about what I think :) I guess files that are described and
explained on the Wiki *and* aren't big should be part of the Wiki...
standalone and/or big stuff probably ought to go on FTP.
> How is backup? Is it it drawn synchronous? If not, a lot of dead links are
> possible in case of a restore... (Had such a case myself some years ago on
> an intranet farm...)
>
Right now the FTP and the Wiki are on the same machine.
> What Rod seems to suggest here is some sort of general suggestion page.
>
I see. I'd say that's what this newsgroup is for!
Or, to put it differently, I don't think Wiki is so good for
*discussing* matters, certainly not nearly as good as a newsgroup.
> BTW: thanks for the <PRE></PRE> ;-) Much cleaner and I will use it in the
> future...
>
Glad to be of help - I ran into this exact problem with formatting
when I was writing some articles.
> (weird use of PRE: http://de.selfhtml.org/html/text/anzeige/pre_style.htm
> really punches the eyes... have a look at the source... quite interesting)
>
The background looks like pure blue, and the text looks like pure
yellow which is green + red. I think that's why it strains the eyes.
Michal
John F
"Michal Necasek" wrote:
> John F wrote:
>
>> MHO: FTP is more flexible, Wiki is more userfriendly...
> That's about what I think :) I guess files that are described and
> explained on the Wiki *and* aren't big should be part of the Wiki...
> standalone and/or big stuff probably ought to go on FTP.
Seems to be a good solution. Will you take care about the uploading? (On
request... I guess there won't be a lot to upload anyways)
>> How is backup? Is it it drawn synchronous? If not, a lot of dead links
>> are possible in case of a restore... (Had such a case myself some years
>> ago on an intranet farm...)
>>
> Right now the FTP and the Wiki are on the same machine.
That's good for backup. Bandwidth problems don't seem to cause troubles in
the near future...
>> What Rod seems to suggest here is some sort of general suggestion page.
>>
> I see. I'd say that's what this newsgroup is for!
Exactly.
> Or, to put it differently, I don't think Wiki is so good for *discussing*
> matters, certainly not nearly as good as a newsgroup.
Well, it's a matter of taste. NNTP is somewhat old and simple.
HTTP-Newsgroups (phpBB ...) seem to be the way to go in the future. The
problem with these is that maintenance is an issue there. More than it is
here.
>> BTW: thanks for the <PRE></PRE> ;-) Much cleaner and I will use it in the
>> future...
> >
> Glad to be of help - I ran into this exact problem with formatting when I
> was writing some articles.
Well, I had something in the back of my mind... I did some HTML years ago...
+ ASP + PHP but I returned to C since it is more challenging and more fun
;-) and you can get big money out of it with less effort... I still take
care about intranet-ware I wrote in those days... was quick and dirty, which
pays back now as I'll have to expand functionality soon...
>> (weird use of PRE: http://de.selfhtml.org/html/text/anzeige/pre_style.htm
>> really punches the eyes... have a look at the source... quite
>> interesting)
> >
> The background looks like pure blue, and the text looks like pure yellow
> which is green + red. I think that's why it strains the eyes.
Did you have a look at the text or just the colors? ;-) Complementary colors
are terrible... technically it is not so good to have black on white too...
try a light (very light) gray! It is worth trying... I work 8-12h in front
of an editor, and I would be blind having it set black text on white
background...
--
John
John F
"Rod Pemberton" wrote:
>
> "Michal Necasek" wrote:
>> John F wrote:
>>
>> > What Rod seems to suggest here is some sort of general suggestion page.
>> >
>> I see. I'd say that's what this newsgroup is for!
>>
>> Or, to put it differently, I don't think Wiki is so good for
>> *discussing* matters, certainly not nearly as good as a newsgroup.
>>
>
> Sorry, I didn't even see a 'discussion' button...
> I take it that's were one normally adds unimportant comments?
Not unimportant... It is rather thought to discuss the content of the
article (to which it is related, that is there is a separate discussion page
for each article) e.g. to suggest changes and corrections before they
actually go online.
So what we were doing here (discussing...) should/could have been done
there.
> I told you wasn't too familiar with Wiki's!!!
That's OK. Have a look at www.wikipedia.org . I'm sure you have heard about
it. It is a free online encyclopedia based on a WIKI system. So if you know
something quite good and find it useful for more than personal use.everybody
is free to add the information. Therefore some errors can be in the
articles, capital errors. But 90% are good and 5% excellent. 5% might
contain terrible errors. If you find an error you are free to correct it. So
it is a self cleaning mechanism that seems to work good here...
--
John
Michal Necasek
> Seems to be a good solution. Will you take care about the uploading? (On
> request... I guess there won't be a lot to upload anyways)
>
Yes, I can do the uploads.
> Well, it's a matter of taste. NNTP is somewhat old and simple.
> HTTP-Newsgroups (phpBB ...) seem to be the way to go in the future. The
> problem with these is that maintenance is an issue there. More than it is
> here.
>
Lots of those boards are big security risks (we had problems with
that), they're way more CPU and bandwidth intensive than news, and I
generally find the ratio of content to fluff extremely low. Newsgroups
are very utilitarian, and I like that.
> Did you have a look at the text or just the colors? ;-)
>
Both.
> Complementary colors
> are terrible... technically it is not so good to have black on white too...
> try a light (very light) gray! It is worth trying...
>
I know - dirty white is much better than pure white.
Michal
Michal Necasek
> What I like in NNTP is that it takes some more effort to actually post. You
> need to find a news-server, get a client (OE does it, XanaNews is great,
> Thunderbird is lousy ;-) ... So spammers are rare in "normal" on-topic
> newsgroups... not talking about alt.* ...
>
I use Mozilla to read news and it works well for me... BTW we do have
some spam here but it's fairly rare. Maybe one post every few weeks.
> When it comes to CPU and bandwidth you are right. But nowadays at least CPU
> shouldn't be a problem.
>
CPU perhaps not, but someone still has to pay for the network bandwith.
Michal
John F
"Michal Necasek" wrote:
> John F wrote:
>
>> Seems to be a good solution. Will you take care about the uploading? (On
>> request... I guess there won't be a lot to upload anyways)
>>
> Yes, I can do the uploads.
OK. Posts should follow here for request then...
>> Well, it's a matter of taste. NNTP is somewhat old and simple.
>> HTTP-Newsgroups (phpBB ...) seem to be the way to go in the future. The
>> problem with these is that maintenance is an issue there. More than it is
>> here.
>>
> Lots of those boards are big security risks (we had problems with that),
> they're way more CPU and bandwidth intensive than news, and I generally
> find the ratio of content to fluff extremely low.
What I like in NNTP is that it takes some more effort to actually post. You
need to find a news-server, get a client (OE does it, XanaNews is great,
Thunderbird is lousy ;-) ... So spammers are rare in "normal" on-topic
newsgroups... not talking about alt.* ...
When it comes to CPU and bandwidth you are right. But nowadays at least CPU
shouldn't be a problem.
There won't be a million hits a day, ~10000 maybe. That would be an
estimated volume of 100k per visitor (if 1/200 does a download of 20MB ...)
and thus this results in 1GB / day... well... total traffic is an issue...
:-) but compared to google its still nothing ;-)
Speed should not be ... <50 MB/h is doable...
> Newsgroups are very utilitarian, and I like that.
Small and handy, indeed.
<SNIP>
>> Complementary colors are terrible... technically it is not so good to
>> have black on white too... try a light (very light) gray! It is worth
>> trying...
> I know - dirty white is much better than pure white.
I don't prefer "dirty" ... at least when it comes to talking about screens
and backgrounds... The default windows light gray is great...
--
John
Rod Pemberton
Okay, you two, I posted some stuff to that page. Check it out.
Rod
Steve Fábián
| John F wrote:
|
| > What I like in NNTP is that it takes some more effort to actually post.
You
| > need to find a news-server, get a client (OE does it, XanaNews is great,
| > Thunderbird is lousy ;-) ... So spammers are rare in "normal" on-topic
| > newsgroups... not talking about alt.* ...
| >
| I use Mozilla to read news and it works well for me... BTW we do have
| some spam here but it's fairly rare. Maybe one post every few weeks.
I use OE to read all my NGs that are NNTP capable. I also found ThunderBird
lousy for downloading all NG articles, though it is more readable when you
have lots of back and forth conversations. IMO NGs that have web-only access
are much harder to deal with, esp. the effort to find all new postings.
JPsoft (4DOS, 4NT, 4OS2, Take Command) is experimenting with bbBoard2, which
is both web and NNTP capable (and also able to send new posts as email) -
the best of both worlds. They also tested phpBoard, but it was foundted
wanting by the large number of NNTP users.
John F
"Michal Necasek" wrote:
> John F wrote:
>
>> What I like in NNTP is that it takes some more effort to actually post.
>> You need to find a news-server, get a client (OE does it, XanaNews is
>> great, Thunderbird is lousy ;-) ... So spammers are rare in "normal"
>> on-topic newsgroups... not talking about alt.* ...
>>
> I use Mozilla to read news and it works well for me...
Um... OK. I heard about problems from others... Multiple message downloads
mostly... I don't know which version they are using or whether they are not
able to get the configurations right...
> BTW we do have some spam here but it's fairly rare. Maybe one post every
> few weeks.
Not as much as to notice it... I couldn't find one in the past month, except
for the weird posts from far east ... :-) + 2 test posts...
>> When it comes to CPU and bandwidth you are right. But nowadays at least
>> CPU shouldn't be a problem.
>>
> CPU perhaps not, but someone still has to pay for the network bandwith.
I know. That's what the donate-button is for... (I guess)
--
John
Michal Necasek
>>BTW we do have some spam here but it's fairly rare. Maybe one post every
>>few weeks.
>
> Not as much as to notice it... I couldn't find one in the past month, except
> for the weird posts from far east ... :-) + 2 test posts...
>
That could be because I'm deleting the spam posts :)
Michal
Steve Fábián
Michal Necasek:
| John F wrote:
| > Not as much as to notice it... I couldn't find one in the past month,
except
| > for the weird posts from far east ... :-) + 2 test posts...
| >
| That could be because I'm deleting the spam posts :)
Thanks, Michal!
--
Steve
John F
I thought there was some cheating involved here ;-)
> Thanks, Michal!
Thanks, Michal too!
--
John
Rod Pemberton
MichalN's porting guide?
openwatcom.users.c_cpp
thread: 1/9/06 "Using Open Watcom as a cross compiler"
post: 1/9/06 11:43 PM MichalN
Rod
John F
"Steve Fábián" wrote:
> Michal Necasek wrote:
> | John F wrote:
> |
> | > What I like in NNTP is that it takes some more effort to actually
> post.
> You
> | > need to find a news-server, get a client (OE does it, XanaNews is
> great,
> | > Thunderbird is lousy ;-) ... So spammers are rare in "normal" on-topic
> | > newsgroups... not talking about alt.* ...
> | >
> | I use Mozilla to read news and it works well for me... BTW we do have
> | some spam here but it's fairly rare. Maybe one post every few weeks.
>
> I use OE to read all my NGs that are NNTP capable. I also found
> ThunderBird
> lousy for downloading all NG articles, though it is more readable when you
> have lots of back and forth conversations.
Have you had a look at XanaNews ? Drawback: only NNTP and no email... but
formatting is great...
> IMO NGs that have web-only access
> are much harder to deal with, esp. the effort to find all new postings.
> JPsoft (4DOS, 4NT, 4OS2, Take Command) is experimenting with bbBoard2,
> which
> is both web and NNTP capable (and also able to send new posts as email) -
> the best of both worlds.
I'll check it out :-) looks good.
> They also tested phpBoard, but it was foundted
> wanting by the large number of NNTP users.
phpBoard is indeed too web-centered for NNTP- (which is quite old indeed,
but since it follows the "no gimmicks" rule it is still around... just as C
is) -Users...
--
John
John F
"Rod Pemberton" wrote:
>
> "Michal Necasek" wrote:
>>
>> > What I like in NNTP is that it takes some more effort to actually post.
> You
>> > need to find a news-server, get a client (OE does it, XanaNews is
>> > great,
>> > Thunderbird is lousy ;-) ... So spammers are rare in "normal" on-topic
>> > newsgroups... not talking about alt.* ...
>> >
>> I use Mozilla to read news and it works well for me... BTW we do have
>> some spam here but it's fairly rare. Maybe one post every few weeks.
>>
>> > When it comes to CPU and bandwidth you are right. But nowadays at least
>> > CPU
>> > shouldn't be a problem.
>> >
>> CPU perhaps not, but someone still has to pay for the network bandwith.
>
Excellent! Thanks! I used # and ## to create a numbered list...
Gives one good insight into what it was intended for and how it was
ported... good stuff.
--
John
Michal Necasek
> Change of topic. Now that you got me to put something on the Wiki. Where's
> MichalN's porting guide?
>
I put it up here: http://www.openwatcom.org/index.php/Porting_Guide
It's my earlier newsgroup post, reformatted and very slightly modified.
Michal
Jed
After a brief burst of stuff in my schedule that has kept me from
programming, I return to find a good answer posted. Thanks! Then I
found many many unrelated posts...
I appreciate taking the time to dig up some code...
~Jed