I'm just curious here: Did you try to dynamically load ntdll.dll using std.loader? I know this module isn't currently in the documentation (it hasn't been actively mantained for a while), but it should be compiled into phobos. At least it is included with the source. It is just a wrapper for LoadLibrary, but I've used it to load windows functions that is too new for the definitions and libs provided by Digital Mars. If this works for you, I know that it isn't your only missing link...

Lars Ivar

> I'm just curious here: Did you try to dynamically load ntdll.dll using
> std.loader? At least it is included with the source. It is just a wrapper for
> LoadLibrary, but I've used it to load windows functions that is too new for the definitions and libs provided by Digital Mars. If this works for you, I know that it isn't your only missing link...
>
> Lars Ivar
>

No but I know that it will work just fine for my example.
But I think it's a short-term solution - dynamic loading is for functions
that present only in some versions of OS or functions you may not always need.

Regards,
Todor

Todor Totev wrote:
>   Hello all,
> after I had read your oppinions I decided to make myself as clear as
> possible.

Cool.

> First, I posted after I successfully compiled, linked & executed my test
> programme. Second, from the beginning I was trying to prove that D is
> excellent as a system programming language. Not application programming
> but system programming.

I don't think it (proving that D is an excellent system programming language) came across this way... Sounded like a long-winded rant to me.  *sigh*.

> 
> According to Wikipedia (http://en.wikipedia.org/wiki/System_programming):
> ...the programmer will make assumptions about the hardware and other
> properties of the system that the program runs on, and will often exploit
> those properties (for example by using an algorithm that is known to be
> efficient when used with specific hardware.
> 
>> If you're referring to your "Problem with COFF library" post, then I'd
> 
> 
> As I stated, I published my thoughts after I found solution of all  engineering
> problems I encounter. The solution is within article
> http://www.digitalmars.com/d/archives/digitalmars/D/9911.html.
> I just didn't realized this at the time I posted that request.
> 

Don't you wish there was an 'undo post' feature? =P  Well, not really. It's good to post your experience on newsgroups that others may learn from your mistakes.  It should follow naturally that you should reply to your post stating that you solved your problem and how you went about it, but it's not required.  I like everything to be out in the open. =)

> 
>> You don't need to link your Python or Ruby executable to kernel32.lib or  gdi32.lib, because the interpreter that runs your Python/Ruby program is  already linked to those.
> 
> Actually every single process in Windows have access to ntdll.dll
> simply because this library is mapped in the process address space even
> before the exe file is being read - actually a code inside ntdll is
> responsible for starting the process :-) No excuse for D.
> 

Ah yes, countless debugging sessions have taught me this knowledge as well, just plum forgot about it =).  But, for D to have *access* to those ntdll.dll functions, it must declare function prototypes for every function in the dll and I guess nobody got around to doing that yet (nor completing the Windows headers translations).

>>> Want to easily convert a .h file to .d? Yes of course! Not with D.
> 
> 
> I really regret for my particular choise of words.
> What I really complain is that Phobos only partially defines very basic
> Windows types AND in the same time Core32 which is supposed to complement  it
> actually clashes with it. So I had to resolve both issues.
> Another problem is that I can patch these but a long-term resolution is to
> fix them inside phobos & core32.
> Of course, I'll send what I discovered to Walter and maintainers of core32.
> 

I understand.

>>>        Plain old, boring Windows 2000/XP functions (5 years old, mind  this)
>>>        are nowhere to be seen. Functions like FindFirstVolumeMountPoint
>>>        or GetVolumePathNamesForVolumeName.
>>>   2.3. No out-of-box support for lib files coming with SDK/DDK/IFS/WDK.
>>>   2.4. No implib functionality so I cannot create up-to date lib files
>>>        from the dll files.
> 
> 
> Again I want to stress that these issues make system programming with D
> near to impossible.
> 

It seems to be that Walter is concentrating mostly on the design and implementation of his language, rather than the details of platform compatibility and standard library development.  Many have complained about the latter, but few have stepped up to actually do something about it.  I applaud those few (no need to name names).

Now, I think you are an excellent candidate for solving some of these problems.  Why not apply your experience working with the Windows APIs and convert some headers for us all?  It's a one time task that everyone can benefit from.

As for me, I don't like to rely on OS-specific behavior and prefer the cross-platform approach to develop my software, which is why I like the phobos approach.

>> If you didn't know, the SDK, DDK, IFS, WDK, whatever from Microsoft are  all proprietary development kits which must be purchased and licensed at  hefty costs.  I'm no legal expert, but knowing Microsoft there is  probably a high barrier to entry for compilers wanting to fully support  the Windows platforms.
> 
> 
> I'm the person responsible for MSDN subscription in our firm.
> SDK costs 0$ - it is freely available for download.
> DDK is free for MSDN subscribers.
> IFS costs 900$ but nearly noone needs it.
> MSDN subscription does cost some money but I cannot imagine a serious
> development for Windows platform without this.
> 

Sure, for us we can just grab a MSDN subscription, but I was leaning more towards the compiler-vendor side of things.  Like I said before, I don't know much about this area at all and I'm just assuming things are different for this market.

>> I certainly wouldn't expect, let alone demand, from Walter that he shell  out cash in the neighborhood of 5-6 figures to Microsoft to get such  support for his compiler.
>>
> 
> Neither I. Walter provides compiler & linker. He surelly does not need
> DDK, unless he decides to prove that compiler can be written as a device
> driver (humourous note).

=)

Yes, I know that might've come off wrong, but I wasn't assuming you were expecting so either.  I meant the cost in terms of the MSDN subscription and/or license-for-redistribution fees.

> It is I who need to bridge D & DDK. And I do have the DDK.
> The problem is that I cannot use it with D because optlink does not
> understands COFF libraries.
> Also, OpenWatcom does understand COFF files in general and MS supplied
> ones in particular out of the box. While Optlink can't?
> 

The COFF2OMF really doesn't do the trick here?  I've never used it myself, so I'm just asking for future reference.  Argh, I don't like when tools do half the job.

>>>  * is not available free if I want to use the digital mars one
>>
>>
>> Digital Mars has to make their income somehow.  The utility CD is $15.  Sacrifice a night out at the movies (which is most likely to be 
>> > $15)  and grab your copy.  This is incomparable to what Microsoft 
>> would charge  you for their compiler toolset.
> 
> 
> The reason I don't wnat to purchase this cd is:
> * I do not have credit card.
> * Things tend to dissapear in Bulgarian customs - i.e. last month
> there was a big scandal because two customs officers have stollen the
> cell phone of the american ambassador while he was checked with metal  detector.
> I still wait for my Ubuntu cds. Although a colleague of mine received his
> DVDs so apparently this is related to man's luck.
> 

Wow, that sucks.  Anything I can do to help?  I'm in the U.S. so I can probably purchase an extra copy for you and send you a digital image via secure transmission.

>>> If I opted for C# I will be ready in less than 20 minutes
>>
>> That's funny that C# takes longer for you than C++?
> 
> Because I must translate c .h files to [DllImport] attributes
> and make some structs. Basically exactly what I did to make D source.
> 

Ah okay.

>>>   And actually that cannot be called "productive". I now must support  three
>>> separate entities: D compiler, DigitalMars C compiler and OpenWatcom   linker.
>>> And of course, for every project I start from now, I must build a bat  file
>>> and linker response file tailored for that project. No build.exe for me.
>>> No simple dmd *.d my.lib my2.lib. Nothing like this.
>>
>>
>> Derek Parnell's 'build' utility (available also on dsource.org) will get  you headed in the right direction here.
> 
> 
> According to the site, build does not know how to handle wlink.
> And my patchy solution relies on OpenWatcom's wlink.
> Besides, it is very interesting that on my complain
> "No build.exe for me." you responded with "Use build".
> 

Hehehe, sorry about that.  I wasn't sure what 'build.exe' you were referring to.

I'm sure it wouldn't be too tough to patch the build source to handle wlink compatibility.  Perhaps another area for your experience to come in to help here?

>>
>>> Ok, my programme is linked and I have an exe file. But as my ex-boss
>>> likes to say: "No-one should commit code in the source control system
>>> unless she had stepped through every one of the new code in the  debugger."
>>
>>
>> While your ex-boss may be a wise man stating this, it shouldn't be a  strict requirement that all code must be stepped-through in a debugger  in order to be bug-free.  True, it may catch many uncaught bugs, but  this is what (and you realize this) the tools the language provides to  you should help to eliminate.
> 
> Please make a multithreaded windows service that runs under LocalSystem  account
> and synchronizes itself with another survice that runs under user account
> right from the first time without using the debugger.
> After that write a book about how did you achieved this and I will buy it.
> I realy do things like thouse to earn my money so I'm touchy on that  subject.

I figured you might come back with a multi-threaded example.  Yes, that stuff is tricky.

Regarding the source control commit, IMO it's still a good idea to commit current working code just so you have a backup somewhere and can easily revert changes.  Of course, the granularity of commits is completely up to the developer and you only get out what you put in.

>>
>>> 3. Where is the debugger?
>>> No near me, for sure.
>>> I hear "WinDbg" screamed, am I not?
>>
>>
>> First off, again you're assuming Windows platform here.  GDC and GDB are  perfectly acceptable alternatives.
> 
> 
> Sure, but I need Windows 2000. If GDC can handle this, why not?
> Remember, I am system programmer doing system programming.
> 
>>
>>> First, it does not come with D/dmd.
>>
>>
>> Nor should it, because it is not a Digital Mars product.
> 
> 
> But comes with Utility CD? Pardon me?
> 

I believe that version contained on the utility CD is an old unsupported version for which nobody else distributes anymore.  Again, I could be wrong.

>>
>>> Second, you must find it in the Microsoft site - not an easy task.
>>
>>
>> This is Microsoft's fault alone.  Personally, I think it isn't all that  hard to find.  Your milage may (and did) vary, of course.
>>
>>> Third, half an year earlier when WinDbg out of the blue got
>>> the docking windows and user interface that made it actually useful
>>> some of my colleague go out, bought some beer and celebrated it.
>>
>>
>> Slapping a GUI onto a tool does not instantly make it "actually useful".    It *might* make it more user-friendly and manageable, but the old tool  was just as useful.
>>
> 
> All these points are valid but did not change the thing that debugger
> is badly needed by the programmer and D does not have a easy to discover  one.
> 

A valid point, but I wasn't commenting on that fact. =)

>>> Fourth, that WinDbg which is quite user-unfriendly does not work with D.
>>
>> If you mean that it doesn't work with D in that you can't peek at local  variables' contents, then I should state that this is a problem with  Microsoft's tools sporting their proprietary PDB file format.
> 
> In the example I provided in another post 100% of programme's state is  inside
> local variables. Debugger that hides 100% of program state is not useful  one.
> Of course this is Microsoft problem, as I admitted at end of my post.
> 

Yes.  It's a shame.

>>>   What other languages offer? Lua, Python & Ruby have built-in
>>> debugging facilities. VisualStudio have a debugger which can be extend
>>> to show your data the way you want it. The dotNet SDK comes with a
>>> debugger (and an excellent one). D simply does not have working  debugger.
>>
>> None of these languages are 'systems programming' languages.
> 
> I use VisualStudio C++ to develop device drivers. Are you sure that
> this do not count as system language?

I didn't notice the VisualStudio in there when I replied earlier.  I was mainly replying about Lua, Python & Ruby here.  Yes, of course C/C++ is a systems programming language. =)

> Also the user interface of the products I develop is written using C#.
> As its sole purpose is to tweak the driver's behaviour it is indeed
> system software. So C# is also system programming language.

I don't agree here.  My school of thought is that if the language alone can be used to develop an operating system with then I consider it a systems programming language.  By your inductive logic here, one could technically consider any language which gives you interop abilities to the OS a system programming language.

IMO, D is a systems programming language because 1) it compiles to native code, 2) you can write an operating system with it, and 3) you can interface to other operating systems with it without special interop abilities needed.

> 
> I wnated to state that every language must have a built-in debugging  facilities
> to be useful. Actually the selling point of D is its debugging features.
> Also both OpenWatcom and free Borland tools come with debugger.
> And they are C++ compilers.
> 
>> They work through bytecode and interpretation (or JIT compilation) which  make it significantly easier to debug and step-through.
> 
> 
> Not for the way I use C++.
> 

Again, I was referring to Lua, Python & Ruby here.  Sorry for the C++ blanket cover.

>> I believe a D debugger project is in the works on dsource.org (dbug?)  but I haven't tried it myself.
> 
> The current state of dbug is:
> http://www.dsource.org/forums/viewtopic.php?t=1009
> "you can set breakpoints by clicking on the leftmost margin in
> the source windows - removing breakpoints isnt finished and its
> getting an exception trying to resume from a breakpoint"
> Not useful to me.
> 

Apparently not; good of you to check though.

>> D is assuming a solid understanding of C and [C++ or OOP in general] as  a start for learning D.
> 
> 
> Completely wrong. D requires from you to learn D and not C/C++.
> What need of C you have to learn OOP or template metaprogramming?
> Do the messy RTTI of C++ helps you to work with D's one?
> Probably the fact that C does not know how large is int really
> helps you to learn using the base types of D?
> Et cetera, et cetera.
> 

What I meant by a 'solid understanding' of C and [C++ or OOP in general] was the flow and structure of C programs (expressions, statements, etc.) combined with the OOP paradigm.  Of course one does not have to learn RTTI of C++ in order to learn D.

> 
> While a book would be great for the
> 
>> business-oriented newbie who is being paid to be trained in the  language, I believe there is no substitue for raw experience gained  while tinkering with the language.
> 
> Never been in paid to be trained in a language and can't talk for this.
> The books help the programmer to get this experience so there is no
> substitusion for them. I tried to learn how dotNet framework works
> reading MSDN and I understood nothing. I read a book for newbies
> and learned how to ask questions and where to look for answers
> (I mean that I learned about System.Runtime.InteropServices,
> System.Management etc namespaces and was able to figure out in MSDN
> what to do to achieve my goals).
>> Once you have the basics down, go ahead and read the reference books/docs
>> to find out what you may have missed in your tinkering sessions.
> 
> Completely opposite: Please go to the site of Lua and check the reference  manual
> (what D have) and Programming in Lua book. You can decide for yourself what
> you want to use to begin learning a new language - the interpreter, the  manual
> or the book.
> 

Everyone learns differently; I was just stating how I learn for a counter-example of why a D book is needed.  I should've pointed that out in my statement.  Self-taught is my way to go. =)

>>>  The requirements for 3rd party tools (namely Microsoft linker,  OpenWatcom suite) and 4th party tools (the patched wlink for DMC) make  the situation as bad as possible.
>>
>> These are not requirements for regular development.
> 
> My regular development includes inter-operating with the OS at low levels.
> I cannot write a notepad-type application without some serious help
> or a framework but I can write a basic WMI provider for less than a hour.
> YMMV.
> 

I meant "regular development" in regular user-mode software that isn't strictly dependent on OS APIs or external linkers to get the job done. =)

>>
>>>  * Provide low level bare metal access as required - it is not even  near,
>>>  as I really need access to ntdll.dll (the lowest level to bare metal
>>>  in user mode available) and D actively hinders me.
>>
>> Bare-metal access does not mean access to operating system libraries. It  means that the code will run on the native processor without requiring  an interpreter or JIT compiler.
> 
> Obvously you dont know that Win32 API is the ultimate virtual machine.
> It is there to shield the programmer from the NT and presents her a
> comfortable, compatible with 16 bit Windows, API.
> If you escape its confines you can create files with names that
> contains embedded zeroes, or that differs only by case of letters, etc.
> Most of the functions inside kernel32/advapi32 either do the work
> without going to the OS level or simply convert ASCIIZ to counted strings
> and ANSI to UNICODE and gives them to the real OS to process them.
> This looks like a tipical behaviour of a VM to me.
> 

Now I understand what you mean.  Okay, you're speaking of the separation between the "high-level" Win32 API and the "low-level" functions present in NTDLL.DLL.  Still, I wouldn't consider this "bare-metal" access.  I would consider this "low-level OS access", i.e. as close to kernel mode programming as you can get in user mode.

>>>  * Be compatible with the local C application binary interface -  Microsoft tools are de facto standard for Windows platform andD does  not talk to them.
>>
>>
>> Microsoft tools were made to force a de facto standard on the Windows  platform because they use and integrate so well their own proprietary  technologies to keep others out.
> 
> 
> Dmd is a proprietary technology so you cannot blame MS doing the same  thing.
> 

??  DMD uses open standards.  I was referring to the 'de facto standard' of their own PE-COFF and PDB formats that their tools use.  Sorry for the confusion.

> Lets give you a hipotetical example. You develop a text editor that
> implements "search in files" functionality.
> Look at this code:
> 
> import std.recls;
> import std.stdio;
> 
> void main()
> {
>   Search s = new Search(null, "*",
>     RECLS_FLAG.RECLS_F_RECURSIVE|RECLS_FLAG.RECLS_F_DIRECTORIES);
>   foreach (Entry e; s)
>     writefln(e.GetPath());
> }
> 
> Do you see the problem?
> Alice as an advanced user had made hard links in her file system.
> But the problem is that one of the hard link goes UP in the file system
> thus if blindly followed forms a never-ending cycle.
> One can recreate the Alice setup using a tool from
> http://www.sysinternals.com/utilities/junction.html
> You can do this yourself and enjoy the show.
> After that come back and tell again that you do not need to
> inter-operate with your OS.
> 

Not sure where this came from, but yes I do see the problem. =)

>> If you had made a case developing for Linux using either the Linux  version of DMD or the GDC front-end for GCC, I'm sure your experience  would have been much more enjoyable.
> 
> Windows 2000. It's what concerns me.
> 

Have you tried GDC on cygwin yet?  I'd be interested to see how the cross-compilation tools that GCC provides work with Windows at the low levels you're working at.

>> To be fair, use the tools that are right for the job.  D might not be  right for your current project, at the current time.  Don't  overgeneralize to everyone else stating that D is a completely useless  language in all areas of development.
>>
> Consider the native string type:
> struct UNICODE_STRING {
>     USHORT Length;
>     USHORT MaximumLength;
>     PWSTR Buffer;
> }
> Now look at D dynamic wchar array
> struct {
>   uint size;
>   wchar* ptr;
> }
> 
> Do you see the resemblance? Both are counted strings and as such
> do not need trailing zero. Both are happy with embedded zeroes.
> Both use UTF-16. D IS the best choice for the job.
> The compiler is flawless! The Optlink is the guardian sitting
> between me and my eternal happiness...

How does a D to C translator sound to you?

> And if there is a statement in my post that can be interpreted
> as "D is a completely useless language in all areas of development"
> then I really regret for the choice of words.
> All I state is that Dmd is very hard to be used as system programming
> language.

Sorry for the assumption, but it sounded like you were coming down on D in a long-winded rant.  I would say the definition of "systems programming language" means different things to different people.

> 
> Thanks for your profound replay, I hope I made myself more clear
> on what my problems are.
> 
> Regards,
> Todor

Todor Totev escribió:
>> I'm just curious here: Did you try to dynamically load ntdll.dll using
>> std.loader? At least it is included with the source. It is just a  wrapper for
>> LoadLibrary, but I've used it to load windows functions that is too new  for the definitions and libs provided by Digital Mars. If this works for  you, I know that it isn't your only missing link...
>>
>> Lars Ivar
>>

I tried that before you posted, and it worked as far as I can tell. Ok, it doesn't really work but that's because I don't know what NtOpenFile does or how it works, etc., so that's where I stopped. It took me less than half an hour. I attached a modified public_test.d. You have to compile with win32\winnt.d and win32\winbase.d. Also, guess what: nothing more than dmd and (opt)link.

> 
> No but I know that it will work just fine for my example.
> But I think it's a short-term solution - dynamic loading is for functions

(I guess Thunderbird didn't download the message correctly)

You must know more than I do about Windows programming, but let me point you at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/winprog/ntopenfile.asp, which is the MSDN documentation for NtOpenFile. That document links to http://msdn.microsoft.com/library/en-us/devnotes/winprog/calling_internal_apis.asp, which says "There is no associated import library, so developers must use run-time dynamic linking to call the functions described in this header file", and later "you can access them through run-time dynamic linking using LoadLibrary and GetProcAddress", which is what Lars suggested and what I did.

--

Don't get me wrong: I understand your problems, but I think 5 hours was a lot more than what you really needed. You mentioned problems with the DM libraries being old, and you're right. That has been brought up quite some times. But there's a practical and useful solution for that. Doing so, also makes your linking problems void. And most (if not all) of your problems with Core32 are solved by NOT importing std.c.windows.windows. Debugging is a problem too, but WinDbg does a fairly good job, and you could've read Wiki4D and find out more about debugging D programs.

Anyway, I hope this particular bad experience doesn't turn you away from D.


-- 
Carlos Santander Bernal

Carlos Santander escribió:
> 
> I tried that before you posted, and it worked as far as I can tell. Ok, it doesn't really work but that's because I don't know what NtOpenFile does or how it works, etc., so that's where I stopped. It took me less than half an hour. I attached a modified public_test.d. You have to compile with win32\winnt.d and win32\winbase.d. Also, guess what: nothing more than dmd and (opt)link.
> 

I forgot the attachment. Here it goes now.

-- 
Carlos Santander Bernal

In article <op.s2h92jx8ihwmk4@todor-1-xp.sanbolic.local>, Todor Totev says...
>I really regret for my particular choise of words.
>What I really complain is that Phobos only partially defines very basic
>Windows types AND in the same time Core32 which is supposed to complement
>
>it actually clashes with it. So I had to resolve both issues.
>Another problem is that I can patch these but a long-term resolution is
>to fix them inside phobos & core32.
>
>Of course, I'll send what I discovered to Walter and maintainers of core= 32.

You're right: Core32 is meant to complement Phobos. We've tried to add "version(STANDALONE)" to all of the statements that are also in Phobos. DMD doesn't complain about conflicts until they are actually mentioned in code that uses both. Some of the conflicts were found by tediously comparing std.c.windows to the Core32 files, and other conflicts were found by "blah conflicts with blah" error statements from DMD. I guess if I were smart I'd come up with some sort of automated tool to find all of the conflicts once and for all, but for now I just version out the conflicts when I become aware of them.

As the guy who maintains Core32, I'd appreciate it if you could help me fix any of the conflicts. Either a new topic in the forum (http://www.dsource.org/forums/viewforum.php?f=16) with the changes or an e-mail with the changed file should do the trick.

I'll also add any definitions that are missing if it's spelled out for me. I know Core32 is out-of-date and incomplete. Mike Wynn did the original conversions from Microsoft's headers, and I don't have the time or talent to convert a bunch of new headers myself. But I'll accept contributions.

jcc7

On Thu, 29 Dec 2005 02:55:34 +0200, Carlos Santander <csantander619@gmail.com> wrote:
>
> I tried that before you posted, and it worked as far as I can tell. Ok, it doesn't really work but that's because I don't know what NtOpenFile does or how it works, etc., so that's where I stopped. It took me less than half an hour. I attached a modified public_test.d. You have to compile with win32\winnt.d and win32\winbase.d. Also, guess what: nothing more than dmd and (opt)link.
>

Carlos, I tried to present a problem where I have a real-world problem and
a valid programme to solve it which is not well handled by the existing
Dmd infrastructure.
To solve the problem I changed the infrastructure to match my programme.
And it takes bloody ages.
On the other hand, you change the programme to match the infrastructure.
I admit the way you walk is the easier one.
My personal opinion is that both solutions work and have their drawbacks as
both are not the solutions of the problem but patches to it.

Also the code I provided was intended to prove that debugger is needed.
Before I had posted it I rolled back to a previous vesion that contains
a tiny mistake and mischievously removed the existing writelfn line
that can easily reveal the wrong code.
What you think is NtOpenFile problem is actually a human problem
left to demonstrate that a debugger is needed.

> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/winprog/ntopenfile.asp, which is the MSDN documentation for NtOpenFile. That document links to http://msdn.microsoft.com/library/en-us/devnotes/winprog/calling_internal_apis.asp,

Both links are 404 now

> which says "There is no associated import library, so developers must use run-time dynamic linking to call the functions described in this header file", and later "you can access them through run-time dynamic linking using LoadLibrary and GetProcAddress", which is what Lars suggested and what I did.

Either Microsoft are so big that MSDN department does not know what OS
department do or MS programmers do not read MSDN.
I have 5 copies of ntdll.lib on my hard (4 from the Micriosoft supplied DKK
and one from OpenWatcom compiler). I can only think that MS does not want
a common application developer to deal with that dll.
Also the Win32 WMI provider implemented in cimwin32.dll, which is a normal
user-mode dll statically links to ntdll.dll so I have an example to follow.


> ...problems with Core32 are solved by NOT importing std.c.windows.windows.

Core32 is intended to complement std.windows as I was made to believe.
Actually this is my fault but is counter-intuitive for me.

> Debugging is a problem too, but WinDbg does a fairly good job, and you could've read Wiki4D and find out more about debugging D programs.
>

The most peculiar thing with Wiki4D is that I use the UltraEdit
syntax highlighter from it. I really can't explain why I missed the debugger
related pages. Thanks for the tip.

> Anyway, I hope this particular bad experience doesn't turn you away from D.

You are kidding! My little programme is working, I really like how D side
of it interacts with Windows Native side of it. I have plans to improve it
and I'm currently downloading my copy of VisualStudio Express which I intend
to convert to dedicated D debugger.

I still miss the ability to conviniently use existing lib files but will
look at build and try to patch it so it starts speaking the language of
Watcom's wlink.

Thanks for the replay, it helped me alot.
Todor

"Todor Totev" <umbra.tenebris@list.ru> wrote in message news:op.s2jo0pu7ihwmk4@todor-1-xp.sanbolic.local...
>Carlos, I tried to present a problem where I have a real-world problem and a valid programme to solve it which is not well handled by the existing Dmd infrastructure.

I appreciate your long and detailed post illustrating the difficulties you're having, and how you got around them. Your concerns are real, and we need to address them.

> I really can't explain why I missed the debugger related pages.

The problem with newer Windbg's from Microsoft is that it can no longer read Microsoft codeview debug information. The old Windbg does work with codeview debug data, it does see local variables in D and D class members. It comes on the Digital Mars CD.

>I still miss the ability to conviniently use existing lib files but will look at build and try to patch it so it starts speaking the language of Watcom's wlink.

Writing a utility to convert Microsoft's dll import libraries to a module definition file, which can then be fed through implib to create an OMF import library, wouldn't be hard. It just takes someone to sit down and do it. Want to take a stab at it?

Todor Totev escribió:
> 
> Carlos, I tried to present a problem where I have a real-world problem and
> a valid programme to solve it which is not well handled by the existing
> Dmd infrastructure.
> To solve the problem I changed the infrastructure to match my programme.
> And it takes bloody ages.
> On the other hand, you change the programme to match the infrastructure.

I don't understand how's that. Could you elaborate, please?

> I admit the way you walk is the easier one.
> My personal opinion is that both solutions work and have their drawbacks as
> both are not the solutions of the problem but patches to it.
> 
> Also the code I provided was intended to prove that debugger is needed.
> Before I had posted it I rolled back to a previous vesion that contains
> a tiny mistake and mischievously removed the existing writelfn line
> that can easily reveal the wrong code.
> What you think is NtOpenFile problem is actually a human problem
> left to demonstrate that a debugger is needed.
> 

I said I didn't know what NtOpenFile does, and since you said something about modifying boot.ini, when the program failed, I said "great" ;) That's why I didn't try harder. Oh, and I was at work.

>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/winprog/ntopenfile.asp,  which is the MSDN documentation for NtOpenFile. That document links to  http://msdn.microsoft.com/library/en-us/devnotes/winprog/calling_internal_apis.asp, 
>>
> 
> 
> Both links are 404 now

Sorry about that. Here's another try: http://msdn.microsoft.com/library/en-us/devnotes/winprog/ntopenfile.asp?frame=true, and http://msdn.microsoft.com/library/en-us/devnotes/winprog/calling_internal_apis.asp

> 
>> which says "There is no associated import library, so developers must  use run-time dynamic linking to call the functions described in this  header file", and later "you can access them through run-time dynamic  linking using LoadLibrary and GetProcAddress", which is what Lars  suggested and what I did.
> 
> 
> Either Microsoft are so big that MSDN department does not know what OS
> department do or MS programmers do not read MSDN.
> I have 5 copies of ntdll.lib on my hard (4 from the Micriosoft supplied DKK
> and one from OpenWatcom compiler). I can only think that MS does not want
> a common application developer to deal with that dll.
> Also the Win32 WMI provider implemented in cimwin32.dll, which is a normal
> user-mode dll statically links to ntdll.dll so I have an example to follow.
> 
> 
>> ...problems with Core32 are solved by NOT importing  std.c.windows.windows.
> 
> 
> Core32 is intended to complement std.windows as I was made to believe.
> Actually this is my fault but is counter-intuitive for me.
> 

I didn't know that either, I just saw conflicts between std.c.windows.windows and Core32, so I tried not importing std.c.windows.windows, and it worked. Then other symbols were missing, so I added more Core32 modules.

>> Debugging is a problem too, but WinDbg does a fairly good job, and you  could've read Wiki4D and find out more about debugging D programs.
>>
> 
> The most peculiar thing with Wiki4D is that I use the UltraEdit
> syntax highlighter from it. I really can't explain why I missed the  debugger
> related pages. Thanks for the tip.
> 
>> Anyway, I hope this particular bad experience doesn't turn you away from  D.
> 
> 
> You are kidding! My little programme is working, I really like how D side
> of it interacts with Windows Native side of it. I have plans to improve it
> and I'm currently downloading my copy of VisualStudio Express which I  intend
> to convert to dedicated D debugger.
> 

Good!

> I still miss the ability to conviniently use existing lib files but will
> look at build and try to patch it so it starts speaking the language of
> Watcom's wlink.
> 
> Thanks for the replay, it helped me alot.
> Todor

You're welcome.

-- 
Carlos Santander Bernal

In article <dp1ce3$m64$1@digitaldaemon.com>, Walter Bright says...
>The problem with newer Windbg's from Microsoft is that it can no longer read Microsoft codeview debug information. The old Windbg does work with codeview debug data, it does see local variables in D and D class members. It comes on the Digital Mars CD.
>

Why not put the "old Windbg" on you D web-site for download? -- because of some license issue?

Or let us know which old version of WinDbg works with D, maybe we can find it somewhere on the web.