Based on your comment, it sounds like you've tried to write a compiler without really knowing how it works, and ended up mixing everything together in one big bowl.
You're talking about using DirectX to write the compiler - but if you're compiling it to some bytecode, then the compiler shouldn't care whether you'll end up using DirectX, GDI, OpenGL, or something completely different. The interpreter needs to care, but if you've abstracted the graphics operations away behind some set of opcodes, then it doesn't really matter what the interpreter uses - you could write an interpreter for each different platform and run the same code.
Compiling is usually easier to do if you use a multi-step process. You may want to consider starting from scratch:
- Make a grammar and write down the semantics for each syntactic construct; not just what each construct does, but what is required for it to do those things (typing rules, etc.). You might find it helpful to look at existing grammars, but it depends on the complexity of your language.
- Write a parser - you can do it by hand or use a parser generator, depending on the complexity of your grammar.
- Write code to check your semantic rules.
- Create an instruction set and define a VM, and use your semantics to convert your constructs to instructions (or use something that already exists). You can handle the "external" things (like graphics) by allocating instructions for each thing, or you could define specific addresses which serve as the target of each type of operation (so if you try to call the function at, say, address 0xF000, then the interpreter must execute code to set a specific pixel to some color). The latter approach gives you more flexibility (and means you can use the opcodes for something else), but at the cost of a more complex implemenetation for the CALL instruction - it's up to you to decide what's appropriate for your needs.
When you have your instruction set, you can easily write an interpreter for it, using whatever you want to handle the graphical stuff (DirectX, OpenGL, GDI, SDL...) - it's pretty much just one big switch statement, with the opcodes implemented as the cases. That's where you place the code specific to whatever you use to draw.
If your problem is that you want to combine those two into a single program, so it will read source files and execute them straight away, then you can do that, but it should still help you to keep them separate in your code. The simplest way to do that is probably to first compile it to bytecode, and then just keep it in memory and letting the interpreter read it there.
Note: You should be aware that writing a compiler is not a trivial task. It's not exactly hard, either, but there are likely a lot of things which you will have to learn about. Consider reading a book about the topic - the so-called Dragon Book is considered one of the best out there, if not the best, but other good books exist. When I learned about this stuff a year ago, we used Concepts of Programmming Languages by Robert Sebesta and Programming Language Processors in Java by David Watt and Deryck Brown. You might want to check your local library to see if they have any of these.
If you want more inspiration, it might help you to look at the report we wrote as part of creating our own programming language at university last year. Ignore the grammar of the language - not only is it a bit buggy, but it's also not serving as a very good example of how you should do it - but the rest of the report might give you some ideas about how to approach the problem.